[Discuss] Meltdown, Spectre, and microcode fixes

[Alan W. Irwin]

On 2018-09-11 14:06-0700 Alan W. Irwin wrote:

> I currently have two questions with regard to Meltdown, Spectre, and 
> microcode fixes:
>
> 1. Could someone explain to me why the fix for these hardware flaws is
> so complex?  For example, all descriptions of what Intel (and AMD)
> have provided in microcode fixes seem to be complex workarounds for
> these fundamental flaws rather than a true fix.  Evidentally from the
> above wikipedia article Intel (and presumably AMD as well) are fixing
> these fundamental flaws (rather than working around them) in the next
> generation of hardware.  Can't they do that with microcode changes to
> their old hardware?
>
> Where I am coming from here is I thought most modern CPU's implemented
> a minimal (but complete) set of instructions in silicon and it was the
> microcode on top that expanded that minimal set of instructions to the
> complete set of machine instructions accessed by compilers.  So I
> thought microcode was essentially all powerful, but if that is the
> general case, why not in this specific case?
>
> 2. What is the relationship between BIOS (or EFFI) firmware fixes and
> microcode fixes?  For example, have I done enough by installing the
> above amd64-microcode package (as well as the firmware-amd-graphics
> Debian Buster package which "contains the binary firmware for AMD/ATI
> graphics chips supported by the radeon, amdgpu and r128 drivers")?  Or
> do I need to update my BIOS (EFFI) as well?  Note that Mother
> Computers did not recommend a BIOS update when they built the box for
> me because they thought BIOS updates were an absolute last resort, and
> that is consistent with previous advice I have gotten from other local
> builders of my Linux boxes over the years.

I am somewhat surprised that I got no answers from list members to the
above fundamental questions, but fortunately I found what looks like a
good discussion of these questions at
<https://superuser.com/questions/1283788/what-exactly-is-microcode-and-how-does-it-differ-from-firmware>.

>From that discussion it appears CPU microcode is Turing-complete.
Nevertheless, despite that power, the answer to my first question is
you need both microcode fixes AND kernel changes to deal with the
Meltdown vulnerability (that occurs for Intel CPU's).
However, theoretically at least all the variants of the Spectre
vulnerability (which affect both Intel and AMD CPU's) could be dealt
with purely by microcode changes.  And the answer to my second
question is BIOS (or EFFI) updates should, in theory update the Intel
or AMD CPU microcode along with potentially a lot of other changes.
But a more explicit method is simply to use OS packages such as
Debian's amd64-microcode package to update the CPU microcode.

Since Meltdown appears to be irrelevant to AMD CPU's (I don't think
anybody has contradicted the AMD claim to that effect other than
Intel), then I only need to consider Spectre vulnerabilities, and from
that perspective it appears I don't need to have an EFFI update and
instead installation of the amd64-microcode package (even though it is
non-free just like an EFFI update) should be sufficient assuming that
AMD are completely on top of all the different Spectre vulnerabilities
caused by their hardware fault.  However, I doubt they are on top of
Spectre yet since new variants keep being discovered so I have
concluded the best way to keep updated on this is via updates to the
amd64-microcode package.

It turns out the installation of that package has a great side benefit
which is it has substantially raised the uptimes possible when the AMD
RX 550 graphics card is being used to display my desktop and run the
low-end 3D game, foobillard.  For example, the last two times I used
the RX 550 before the above package installation, the box achieved
only half hour and 8 hours of uptime before locking up (in both cases
when I was not running foobillard).  Since that package installation
it has not locked up at all with uptime currently at 6 days and
counting.  So I am encouraged by that result.  Furthermore, it is nice
to see the graphical results from the AMD RX 550 which are noticeably
better than the integrated Nvidia graphics results I get from my
X-terminal when I needed (before the above package installation) to
avoid use of the RX 550 to provide stability for the new box.
However, I run my new box 24x7 so my uptimes (when the equipment and
setup are really stable) typically exceed two weeks before I have to
bring down the box for some legitimate reason such as a new kernel
version.  In sum, it is early days yet on the current stability test,
but so far it is much better than before!

Alan
__________________________
Alan W. Irwin

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
__________________________