From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-user+bounces-181944-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 61321138330
	for <garchives@archives.gentoo.org>; Tue,  9 Jan 2018 13:35:46 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 2666DE0AB4;
	Tue,  9 Jan 2018 13:35:38 +0000 (UTC)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244])
	(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 AA659E0AA5
	for <gentoo-user@lists.gentoo.org>; Tue,  9 Jan 2018 13:35:37 +0000 (UTC)
Received: by mail-pf0-x244.google.com with SMTP id t12so5712290pfg.2
        for <gentoo-user@lists.gentoo.org>; Tue, 09 Jan 2018 05:35:37 -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=pkAQAIAXN+H4mq8XmdZr7pN9uNN3OjAMkLSZrjdI+Qk=;
        b=UXX2PhpriNc21xX/ahHsEIP1inp33Y9RlBCJ+YhRv0f/txtXtjoqvFLZ1sQhGYvcOV
         5bpiWkPay7KYdDQeSrbvYuZDYCoEtnRbpgc2t2bBff/4kp/n0gtO63nqXHtQA7mfNZ01
         T81lDR713Fyl5cKGquEMF0sF935bG0erSoloBnur1vD+IiU0mkIXsJpkcJ3xUJ19fW/O
         uugTiYAUx/KNX5g/IXdJMHGX5pRaoh98lVUQb31MGuOmnAMmmxpAusNcotpEfJTqrk1a
         xwHBoDfgZv6oV4pIGmv1yu90FNd1v/iv7ql3YJ9lv09vp6+x8kF7ICiKnzeNDIr7WjeT
         mIEg==
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=pkAQAIAXN+H4mq8XmdZr7pN9uNN3OjAMkLSZrjdI+Qk=;
        b=Cx5A6UE8tQv7Czu0CC1s1kYM0KzdAzYpo0JfOqfVYy9pj7EbiVrrleCeL5gKq1do8L
         jHe2ECXKlSgbGzhMxGsUmaP/cMsWkxodwCauCNuF6BNwwrgJ3vATIMnOtlQ7VNeZW+tA
         IlC69f2wDybxSK4XNMazMvfrvVmBzJ7KkKCei/TAqdEV36LhL4ctrRYuOh2LicSAxyxH
         mtpeJ4BRPwISGFR/B60ygtfd5sTLEaUKiquzf/hWzoqyA/1XcXs31FVGZ7e5PhPAFI6N
         di+B8KMM5QD5Qihi91DboScbDYucUJiN1JAmVvfUPV0ftESLfj8izUaN/GJZfHhGjsvc
         v39w==
X-Gm-Message-State: AKGB3mL8daBZJqpBjP7Q1/kOL/EddsigdiwSkWu/7qXfc6hoUiXm6djn
	fRpVQOFqjdF2yrp80378gJ+FIKcaFtW72tjCoCoN00RI
X-Google-Smtp-Source: ACJfBoub4soWS9wlBR3HFApf3pj2XR3zHK9Dz3nqdwTdWdCgGCHcgminKbnmPlYUgGPxOo+dEHjWMNquNEM8f2TZMik=
X-Received: by 10.84.246.21 with SMTP id k21mr15944418pll.174.1515504936144;
 Tue, 09 Jan 2018 05:35:36 -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; Tue, 9 Jan 2018 05:35:35 -0800 (PST)
In-Reply-To: <5A548AA9.3010205@youngman.org.uk>
References: <CAC=wYCH8uy2+FBhKPTwA6_XjozCaHZbVZ+yquWmLb6ah2P27bQ@mail.gmail.com>
 <CACjvM=cvhDxeaYV2WvNiUC=rCpyTo1aoyR+P41TQU9bE7NvB=w@mail.gmail.com>
 <L2J3sag--3-0@tutanota.com> <CAGfcS_mtw6mPKye7sci=SPk0ZdqANuQ36mM44=0uU_BP5FXNfw@mail.gmail.com>
 <5A548AA9.3010205@youngman.org.uk>
From: Rich Freeman <rich0@gentoo.org>
Date: Tue, 9 Jan 2018 08:35:35 -0500
X-Google-Sender-Auth: xmS0IM_twgOcDVt5tkc2zgmYxtE
Message-ID: <CAGfcS_ntNJDhD4qjwy+-201WZfoOQeOcmEycDQERLCb3yDdG_A@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: f708a56e-42c4-4299-bd23-927ad48b0497
X-Archives-Hash: 85dffed3600826ef11048d8f93af3b06

On Tue, Jan 9, 2018 at 4:26 AM, Wols Lists <antlists@youngman.org.uk> wrote:
> On 08/01/18 13:52, Rich Freeman wrote:
>> 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.
>
> Probably not much point co-operating. The *internals* of AMD chips and
> Intel chips are very different. I suspect both of them have a RISC core
> with an x86 instruction set interpretation layer, but that's where the
> similarities end ...
>

The fact that their internals are very different is EXACTLY why they
need to cooperate.

Spectre cannot be remediated in existing CPUs with a microcode update
only.  It might not even be possible to completely fix it in future
CPUs with only a hardware change.  Spectre remediation (at least at
present) requires software changes as well.

Software is written to the ISA, and both Intel and AMD share a common
ISA for the most part.  It is impossible for a programmer to know how
the internals of the CPU actually work, so they write their code to
the ISA specifications.  If the ISA says to insert an LFENCE
instruction immediately after every bounds check then programmers (or
at least compiler designers) will do just that.  If it says to insert
a CPUID instruction after every bounds check then that is what
programmers/compilers will do.

However, if one of the major vendors tells everybody to do one thing,
and the other tells everybody to do another, and each writes their
microcode fixes to work only their way, then programmers are stuck
trying to reconcile them.  The two vendor CPUs are no longer truly
instruction-set compatible for typical software.  Adding a lot of
conditional branching anytime there is a bounds check to try to detect
the CPU and deal with it isn't a great workaround either, because
branching is what causes the problem in the first place - it would be
better to determine the correct fix at compile-time and not runtime.

Intel and AMD don't need to agree on how to fix the internals of their
CPUs.  What they do need to agree on is the changes that need to be
made in the ISA.

Since AMD has been relatively quiet I suspect they intend to just let
Intel define the fix, and then quietly patch their CPUs to accept the
same fix, or at least to not have any issues when the Intel fix is
used.  However, the fact that they quietly issued a microcode update
doesn't go along with that, especially since they haven't provided any
clarification on what it does, or whether anything needs to be done
with software to take advantage of it.  Intel, while not being all
that cooperative, has at least issued unambiguous statements on what
needs to be done to remediate everything.

-- 
Rich