[Discuss] Help needed in trying to figure out how the various Meltdown and Spectre mitigations fit together

[Alan W. Irwin]

Hi Again, Cy:

On 2018-01-19 02:28-0800 Alan W. Irwin wrote:

> On 2018-01-18 23:00-0800 Cy Schubert wrote:
>
>> I suppose MB manufacturers could reflash BIOS to include firmware however
>> it's simpler to let the O/S do it, distributing microcode to O/S vendors
>> who can package it as patches.
>> 
>> Depending on the CPU, a microcode update is simply writing the microcode to
>> one of the machine status registers. The microcode update is erased the
>> next time CPU is reset, i.e. reboot, and must be loaded again next boot.
>
> Some of the articles I read used the term "firmware" while others
> specifically mentioned BIOS changes.  But the BIOS is one kind of
> firmware so I suspect the two terms mean the same in the context of
> Meltdown and Spectre.  I do agree there is another kind of firmware
> like you describe that can be dynamically loaded at boot time, but I
> am pretty sure that is not what is being referred to in the articles
> simply because some of them specifically mentioned BIOS changes.

That interpretation turned out to be incorrect, see below.

>
> Another twist in understanding how everything fits together (see the
> later post from me) is Google came up with what they felt was a
> complete fix for all 3 variants in December long before Intel and AMD
> distributed the first of their "firmware" updates.  So I am fairly
> sure that if no issues are spotted with the google approach, no
> firmware updates will actually be required.  But I am right at the
> limit of my understanding here so I might be misinterpreting what the
> Google approach really was that they completed in December. Thus, if
> you find an article that clearly contradicts my "no firmware updates
> required" interpretation of how Google addressed the 3 issues, I would
> be most interested in reading it.

Based on the article below I am still sticking with my interpretation
that no firmware updates will be required (at least for AMD, but from
what google has said likely Intel as well).

I have found a really helpful article that answers most of my
questions about how all the various mitigation efforts fit together.
Is is (rightly) entitled "A Clear Guide to Meltdown and Spectre
Patches", see
<https://blog.barkly.com/meltdown-spectre-patches-list-windows-update-help>.
This article was updated yesterday.

It appears to cover all chips and OS's (and some important browsers as
well), but my forthcoming new box will be AMD so that (and Linux, of
course) is what I will focus on here when summarizing the relevant
bits of the above article.

* AMD not subject to Meltdown (which by itself is a good reason for avoiding Intel).

* AMD claims OS patches are enough to mitigate Spectre variant 1.

* AMD will be rolling out *optional* microcode updates this week,
starting with fixes (presumably just to mitigate the tough one,
Spectre variant 2) for Ryzen and EPYC processors.

Also, such updates (as you stated) can be loaded at boot time and
aren't (necessarily) deployed as a BIOS or UEFI change. Note that such
"boot-time" AMD firmware is kept for Debian in the amd64-microcode
package which is described as "This package contains microcode patches
for all AMD AMD64 processors. AMD releases microcode patches to
correct processor behavior as documented in the respective processor
revision guides."

However, such proprietary firmware updates from AMD are obviously not
free software so they are rightly segregated by Debian into the
non-free part of the distribution.  And as a free software advocate
and user, I would far prefer not to rely on such firmware loaded at
boot time to mitigate Spectre variant 2.

Fortunately for me, google claims that retpoline (which they have
licensed as free software and which is headed into the Linux kernel
and already supported by gcc) is the best way to mitigate Spectre
variant 2.  Therefore, it looks like my new system won't require AMD
firmware loaded at boot time.  (Note if I can find a suitable motherboard
for the Ryzen 7 1700 that is compatible with OpenBIOS
<https://en.wikipedia.org/wiki/OpenBIOS>, I could potentially
eliminate all proprietary firmware from my system!)

Of course, one question mark still remaining concerning the above
interpretation is the further statement in the article that

"Organizations need to be prepared for UEFI firmware and
BIOS updates, as well".

For now, though, I assume that would be just an alternative way (you
already mentioned this possibility) to get the (unnecessary for AMD)
microcode updates distributed.  So I hope this statement will not be
relevant to me.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________