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

[Alan W. Irwin]

On 2018-01-17 17:15-0800 pw wrote:

> My crystal ball says that CPU prices will decline over the next few
> months as people begin waiting for fixed CPUs.

I suspect it is going to take years to get fundamentally fixed CPU's
(where speculative execution absolutely cannot access protected
memory).  In other words, I am pretty sure the firmware fixes from
Intel and AMD that we see now are just workarounds for the fundamental
flaws, and it may turn out those firmware fixes are not needed in
the slightest.

I have come to that view as a result of learning a bit more about how
google feels that mitigation is supposed to fit together.  (Note, this
is the google view that mitigation is now perfect for their server
farms, but time will tell on whether that is a realistic view or
optimistic.)

To learn more I followed up on what was meant by retpoline (a.k.a
return + trampoline to help to remember the spelling), and apparently
this compiler change (to do something special with returns from
routines) and compiling the kernel with that option are the best way
to mitigate Spectre variant 2 (the toughest of the exploits to
mitigate) for most hardware (including Intel and AMD). And kernel
patches mitigate Spectre variant 1 (an issue for both Intel and AMD)
and Meltdown (not applicable for AMD, but a major issue for Intel). So
the result was google felt their approach mitigated all speculative
execution exploits for their server farm as of December and since they
open-sourced their retpoline approach (kudos to them for that!), they
felt this approach is the best one for the entire computer industry
with no necessity for firmware patches (definitely for Spectre variant
2, and my guess is they felt this was true for Spectre variant 1 and
Meltdown as well since I cannot imagine the enormous pain of being
forced to flash all Intel boxes for the google server farm).  So if
you believe google is right, it should only be a matter of a
relatively short time for Linux users to wait for the required
compiler and kernel changes to propagate to their distribution, and
after that game over for all these exploits on Linux!  And similarly
for Windows and Mac OS X assuming their kernel developers know what
they are doing.

> Maybe set your number of cores sights a bit higher, wait for the proces
> to drop, don't worry about the CPU defect because it
> can't really be fixed.

Assuming the above google view is correct (and my interpretation that
no firmware fixes are required with their approach also proves true),
I think this short-term wait is the right approach for me since it
will likely take a month or so for the gcc and kernel changes to
propagate to my preferred distribution (Debian stable).  And it would
be nice if the price dropped during that time, but I am not counting
on that so it is not the principle driver for the decision to wait
a short amount of time.

> All workarounds are crackable.  The kernel needs to be patched
> to avoid unintentional data snooping, but that doesn't stop
> anyone from making kernel modules with rogue asm statements in them.

Well rogue kernels mean your computer is completely owned by someone
else and are, by definition, always going to be a security issue.  But
if you eliminate the possibility of a rogue kernel, I also have to say
I am not quite as confident (just on general paranoid principles) as
google that their approach is perfect, and ultimately the far better
approach is to eliminate all these really stupid speculative execution
chip flaws (at least in new chip designs).  But that fundamental type
of fix is likely not going to happen on anything but a long time scale
so I don't plan to delay my buy for that reason, but I will delay it
to wait for a short while to allow propagation of the fixes to Debian
stable and also to give me a better idea of whether the comforting
google assessment can be trusted or not.

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
__________________________