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