From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-user+bounces-181924-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B2123138330 for <garchives@archives.gentoo.org>; Tue, 9 Jan 2018 02:45:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 11EE5E0AE8; Tue, 9 Jan 2018 02:44:58 +0000 (UTC) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 99242E0AD5 for <gentoo-user@lists.gentoo.org>; Tue, 9 Jan 2018 02:44:57 +0000 (UTC) Received: by mail-pf0-x232.google.com with SMTP id e3so7504758pfi.10 for <gentoo-user@lists.gentoo.org>; Mon, 08 Jan 2018 18:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=wKm5AELR5+pOCY+vLJiD8eM5Fi6p06MmcdsA8owF0mg=; b=PzV5Kiix6fKCcxfPEsUt66oZ1UeuLGpj0tbbG+oPfGI9UIuUE7xnPUdg6AWnsAKGvm S0hZJXRB035mXE1Ak6X2ew0PBQfFvjvUWvyEGHjtrt5jrsBDRCslbTWRwY0Z4Ayqrkqw /nX1eqeewoPTBEN3Ji4RTp3LNAseiala1ML+MPITRtVyzCncyDA8s1htzqOnlWcwiEJ1 DvpKckl6uUokfhN9TmeqvQOXESMnLWZDMwR6DFuVSIERLOnSrR8C7isBM6vLTvLYKi5S ZoQoX+p4hD7NvqzJ9mQPEQ+hfOkNhLa5xjaP/ZmTSAHMaApaE88iApiP/ro/pt4KfbqZ nxpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=wKm5AELR5+pOCY+vLJiD8eM5Fi6p06MmcdsA8owF0mg=; b=jU4CIt6bNPBFZTItZ/zgQHXT5YjmyBd7xOaa5+NapmJj2+Eorj7G8jqSNVVoZ5AcFP 3GbqZFwd/HseId/SshAfuDQYBdSBd7hFDCJyU5jgXvJGcuzWo0fqHHO58ejGEDuDgKRT pk29D5v44aqq5mM3BCd4goiUX5QjbYz+qlnfSDX56lGy4YnZH+U4TLXah60kXyPJ6NMz NkB6Z19XpxiSSANAZHYoagC/VsmrV81NvjDKxd/6Wy7NPQEAr8/BxWEGj8LZAIYVhUCm epCYpFIJqgauLXW8pDiBPlylJ9eT7+A0lDy4td7ZiOQPe0kVrwKvyMKRJg0K3CKAOzk4 SBxA== X-Gm-Message-State: AKGB3mL36QiNC2FFFfk1yag1+Rq+6EasbD89dmpMpovM1ybt5ntzgWv8 h4oZcyL0/TTD2sdeq2cX7keCQZ2QhFkSy05kWSt26SDm X-Google-Smtp-Source: ACJfBoukGYAFwTLuuznl6X7j+q2yG5nxr4ms7503P0pHpYob4ddNuv9tgfkhHxiIxgtlS4LFkZ8748M/StFHAr7r7/4= X-Received: by 10.159.194.4 with SMTP id x4mr12523903pln.111.1515419566382; Mon, 08 Jan 2018 05:52:46 -0800 (PST) Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Sender: freemanrich@gmail.com Received: by 10.100.151.169 with HTTP; Mon, 8 Jan 2018 05:52:45 -0800 (PST) In-Reply-To: <L2J3sag--3-0@tutanota.com> References: <CAC=wYCH8uy2+FBhKPTwA6_XjozCaHZbVZ+yquWmLb6ah2P27bQ@mail.gmail.com> <CACjvM=cvhDxeaYV2WvNiUC=rCpyTo1aoyR+P41TQU9bE7NvB=w@mail.gmail.com> <L2J3sag--3-0@tutanota.com> From: Rich Freeman <rich0@gentoo.org> Date: Mon, 8 Jan 2018 08:52:45 -0500 X-Google-Sender-Auth: RjzyDrk9RaeZs5VUP1bqEgYcLxY Message-ID: <CAGfcS_mtw6mPKye7sci=SPk0ZdqANuQ36mM44=0uU_BP5FXNfw@mail.gmail.com> Subject: Re: [gentoo-user] microcode applied? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: f655b7a4-8b9a-4afa-9d78-493827b1452e X-Archives-Hash: 38ff79a7e998ba3549a035a8c45d63f3 On Sun, Jan 7, 2018 at 11:42 PM, <mad.scientist.at.large@tutanota.com> wrote: > You really can't fix it completely in > software on either brand, at best you are counting on code to protect code > from a hardware on intel, and more mild but still dangerous design issues > on both. As far as I can tell from the various emails/postings you can actually fix this entirely in software on AMD, though it might be better solved with a combination of microcode and software. Variant 3 doesn't impact AMD. Regarding variant 2: https://lkml.org/lkml/2018/1/4/742 (which seems to be down right now, so I'll also post:) https://webcache.googleusercontent.com/search?q=cache:i47fyooNn4UJ:https://lkml.org/lkml/2018/1/4/742+&cd=1&hl=en&ct=clnk&gl=us Regarding variant 1, I suspect this could be fixed with a call to something like CPUID, though that probably will impact performance a bit in critical code, and it probably could also be fixed by tossing in some instructions to manipulate either speculative execution or the cache (such as forcing the CPU to fetch both possible target addresses into the cache to make it impossible to tell which branch was followed). Using LFENCE (which is what Intel recommends) apparently requires an MSR setting or maybe a microcode update. I haven't actually tested CPUID on the released spectre exploit code, but I have confirmed that LFENCE doesn't fix it at all without the microcode/MSR fix. The main advantage of microcode updates would be that you could probably reduce the complexity of the software fix and maybe improve performance. Not speculatively executing something will always have some performance hit, but it could be minimal. There is also an AMD microcode update floating around (which Gentoo just deployed), and I can't figure out what it actually does, because AMD hasn't said a word about it. I can't imagine that anybody other than AMD wrote it, so I assume it went through back channels (Suse was the first to come out with it). Suse says that it disables branch prediction, and everybody else seems to be going with that description (though the upstream kernel team hasn't accepted the change). Obviously it can't completely disable branch prediction without clobbering performance so it is a mystery as to when it actually does disable it. I haven't deployed the kernel patch to load it yet so I haven't had a chance to test the spectre variant 1 code with it. There is also a lot of discussion on lkml about the right fix. We might very well end up seeing both AMD- and Intel-specific fixes with conditional logic. The two vendors don't really seem to be coordinating on this. Intel is pushing patches that apparently don't work on AMD, or aren't necessary on AMD. AMD for its part hasn't been pushing much in public at all, but has made a few list posts, and they have that mystery microcode update. I suspect that that Linux will either adopt conditional AMD vs Intel code, or will force a compromise that works on both. I have no idea what that will end up being. Once that happens I wouldn't be surprised if we see GCC adopt a fix to apply the software side of that automatically. -- Rich