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

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

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf

From
https://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/

"The new guidance
<https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf>,
issued April 2, adds a “stopped” status to Intel’s “production status”
category in its array of available Meltdown and Spectre
<https://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/>
security updates. "Stopped" indicates there will be no microcode patch to
kill off Meltdown and Spectre."

" "Stopped" CPUs that won’t therefore get a fix are in the Bloomfield,
Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 and E0, Jasper
Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield, and
Yorkfield Xeon families. The new list includes various Xeons, Core CPUs,
Pentiums, Celerons, and Atoms – just about everything Intel makes.

Most the CPUs listed above are oldies that went on sale between 2007 and
2011"

[-- Attachment #2: Type: text/html, Size: 1428 bytes --]

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

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

On Thursday, 5 April 2018 10:20:59 BST Adam Carter wrote:
> https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-upd
> ate-guidance.pdf
> 
> From
> https://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/
> 
> "The new guidance
> <https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-up
> date-guidance.pdf>, issued April 2, adds a “stopped” status to Intel’s
> “production status” category in its array of available Meltdown and Spectre
> <https://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/>
> security updates. "Stopped" indicates there will be no microcode patch to
> kill off Meltdown and Spectre."
> 
> " "Stopped" CPUs that won’t therefore get a fix are in the Bloomfield,
> Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 and E0, Jasper
> Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield, and
> Yorkfield Xeon families. The new list includes various Xeons, Core CPUs,
> Pentiums, Celerons, and Atoms – just about everything Intel makes.
> 
> Most the CPUs listed above are oldies that went on sale between 2007 and
> 2011"

Thanks for updating the gentoo-user M/L on this topic Adam.

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 asking because 
I have a couple of old laptops I was hoping to get more mileage out of, at 
least until new generation CPUs become available.  Preferably NOT Intel's.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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@gmail.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

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

[Wols Lists]

On 05/04/18 17:54, Rich Freeman wrote:
> 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.

Is lfence a meltdown problem? Because afaik Ryzen doesn't need a fix for
meltdown, it's not vulnerable.

As for Spectre, it's inherent in modern CPU design. There IS no fix,
other than going back to the drawing board and scrapping years of
optimisation, making computers maybe 30% slower :-(

I don't think Spectre IS fixable. Sure we can play whack-a-mole, but
unless we rip up the lawn and replace it with concrete, the problem will
simply come back in another guise.

Cheers,
Wol

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

[Rich Freeman]

On Thu, Apr 5, 2018 at 3:36 PM, Wols Lists <antlists@youngman.org.uk> wrote:
> On 05/04/18 17:54, Rich Freeman wrote:
>> 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.
>
> Is lfence a meltdown problem? Because afaik Ryzen doesn't need a fix for
> meltdown, it's not vulnerable.

No, lfence is exclusively a fix for spectre.   It has nothing to do
with meltdown [1].

lfence itself has been around for a while, and works fine for its
original purpose.  It was intended to serialize reads from memory, so
that any previous read operations were guaranteed to be complete
before the lfence retires and execution moves on.

However, lfence as it was originally defined does NOT prevent the CPU
from fetching subsequent data into the cache, or to speculatively
execute (but not retire) instructions.  That is enough to allow for a
spectre vulnerability.

I believe the intent of these microcode changes is to basically
overload some additional functionality on top of lfence that prevents
some forms of speculative execution from continuing past it.

However, I haven't really read much about the changes since the
original publicity.  At that time one concern I had was that it seemed
like Intel and AMD were independently solving the problem, creating
the potential that a code fix might work on one vendor's CPUs and not
the other's.


1 - As a footnote, it makes sense that lfence couldn't do anything for
Meltdown.  Spectre is like most vulnerabilities in that it is a
problem that must be present in the code that is being attacked.
Meltdown is more of a hardware problem - you don't need any vulnerable
code on a system to attack it.  Now, meltdown does have a workaround
that can be done at the kernel/hypervisor level.  You can't fix
meltdown simply by sticking instructions in the kernel's code path
because when meltdown is exploited there isn't any kernel code
running.  With spectre the program being attacked IS the program that
is running so it can control the instructions being run.

-- 
Rich