Re: [gentoo-user] List of Intel CPUs that wont get Meltdown/Spectre fixes

[Rich Freeman]

On Thu, Apr 5, 2018 at 12:34 PM, Mick <michaelkintzios@×××××.com> wrote:
>
> Does the lack of a microcode patch mean the in-kernel and other software fixes
> won't be sufficient to protect PCs running these old CPUs?

I'm interested if somebody has a more informed answer, but my guess is
that it would result in a less efficient fix being applied by the
kernel.

I'm not sure if Intel actually has any good fixes for meltdown in
microcode.  The in-kernel fix for that is fairly expensive, and if it
could be fixed in microcode that would be a big savings (assuming the
microcode didn't add a cost).

My understanding is that most of the microcode patches are for spectre
and modify the behavior of lfence to block vulnerable speculative
execution.  This still has some cost to it, but it is minimal.
Without the microcode fix I imagine the vulnerabilities could still be
fixed via retpolines and similar techniques, at a higher cost.  I
haven't checked recently but the last time I looked at it even my
current Ryzen CPU doesn't have a microcode fix out yet for lfence.

I haven't read up on what has changed in the last month or two, but
the gist of it is that with spectre you have three options:

1.  Ignore it.  Some code is vulnerable.  No performance cost.
2.  Add a series of instructions to vulnerable code so that
speculative execution is blocked on any processor.  The code is no
longer vulnerable, but those instructions can add some cost (not as
bad as with meltdown).
3.  If the CPU+microcode supports it, add a single lfence instruction
to vulnerable code.  This will address the vulnerability at a lower
cost.

In an ideal world we wouldn't need #2.  That would not only make the
fixes perform better, but it would also mean that compilers wouldn't
have to generate code that figures out whether scenario 2 vs 3 applies
AT RUNTIME and do the right thing.

Now, if 95% of users fall into bucket 3 and 5% fall into bucket 2 you
have an interesting situation.  Will software developers take the time
to ensure that scenario #2 is even covered, except for the most
at-risk code (such as browser sandboxes)?

Granted, I think in reality an awful lot of software will just fall
into bucket #1 for the same reason that we STILL keep finding buffer
overflows.  That, and people will think of new situations where
spectre applies that aren't presently known.  I don't think we're at a
point where a compiler can reliably determine whether a
retpoline/lfence is actually needed.  The last time I checked the GCC
fixes needed the code to be tagged in some way to tell it to add the
protection (when you think about it C doesn't even do bounds checks,
let alone figure out when you're about to do a dangerous one).

-- 
Rich