[Discuss] Meltdown, Spectre, and microcode fixes
Alan W. Irwin
Alan.W.Irwin1234 at gmail.com
Tue Sep 11 14:06:49 PDT 2018
This topic is a follow up to the article at
<http://www.eweek.com/security/linux-kernel-developer-criticizes-intel-for-meltdown-spectre-response?utm_medium=email&utm_campaign=EWK_NL_LOSU_20180904_STR1L1&dni=454210202&rni=32850099>
recommended by Murray.
I have organized this post as essential background first followed up by my two
questions at the end.
___________________
Background:
The article above has the following quote:
"While there have been many patches made in Linux, he [Greg K-H] strongly advised
users to update with Intel's microcode fixes as well, as they provide
an additional layer of protection beyond what an operating system can
provide."
In my case I have AMD equipment, but although AMD CPU's are not
subject to Meltdown, my understanding is they are subject to the same
varieties of Spectre exploits as Intel CPU's due to similarities
between the AMD and Intel CPU hardware faults. So I assume the
principle would be the same, i.e., I should update the AMD CPU
microcode in the way recommended by AMD.
The non-free variant of Debian Buster = Testing has a package called
amd64-microcode which is described as follows:
"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."
So I have installed this package and one side-benefit of this upgrade
motivated by security concerns seems to be my RX 550 graphics card has
suddenly got much more stable (currently I have 4 days uptime as
opposed to uptimes of half-hour to two days that previously occurred
before a kernel lockup was encountered).
One final piece of background information is according to
<https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)> "On
most processors, the speculative execution resulting from a branch
misprediction may leave observable side effects that may reveal
private data to attackers." That is, bypass most of the security
measures implemented in the kernel which is why these fundamental
hardware flaws have such huge consequences.
End of background
___________________
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.
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
__________________________
More information about the Discuss
mailing list