Re: [gentoo-user] microcode applied?

[Rich Freeman]

On Tue, Jan 9, 2018 at 4:26 AM, Wols Lists <antlists@××××××××××××.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