On Wed, Jan 24, 2018 at 12:56 AM, Ralf Corsepius <rc040203(a)freenet.de>
On 01/23/2018 07:45 PM, Justin Forbes wrote:
> On Tue, Jan 23, 2018 at 10:49 AM, Ralf Corsepius <rc040203(a)freenet.de
> <mailto:email@example.com>> wrote:
> Recent Fedora kernels report
> # cat /proc/cpuinfo | grep bugs
> bugs : cpu_meltdown spectre_v1 spectre_v2
> on my PIII and my N270s (I.e. all i386ers, I have).
> To my knowledge, this is entirely bogus.
> Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1537625
> I have some bad news for you, it isn't as bogus as it seems. Noted in the
> bug. For more information see https://meltdownattack.com/
> "Desktop, Laptop, and Cloud computers may be affected by Meltdown. More
> technically, every Intel processor which implements out-of-order execution
> is potentially affected, which is effectively every processor since 1995
> (except Intel Itanium and Intel Atom before 2013). We successfully tested
> Meltdown on Intel processor generations released as early as 2011.
> Currently, we have only verified Meltdown on Intel processors. At the
> moment, it is unclear whether AMD processors are also affected by
> Meltdown. According to ARM, some of their processors are also affected."
> "Almost every system is affected by Spectre: Desktops, Laptops, Cloud
> Servers, as well as Smartphones. More specifically, all modern processors
> capable of keeping many instructions in flight are potentially vulnerable.
> In particular, we have verified Spectre on Intel, AMD, and ARM processors."
> The feature which enables these attacks is out of order execution. Your
> atom doesn't have it, your PIII does.
OK, this is news to me. From what I had read in the press so far, I had
assumed both the PIII and the Atom not being affected, because of their
ages - But you probably are more intimate with these bugs than I am ;)
This begs for an other question: Is there a Linux rsp. Fedora test suite
or similar to check cpu for these vulnerabilities?
Unfortunately it is not so simple. They are possible by a CPU feature that
doesn't exactly get listed in CPU flags because the OS should have never
had to care that the capability existed. While meltdown can be generally
exploited, it would literally require writing an publishing exploit code to
check for the vulnerability. The Spectre variations are much harder to
exploit, and even this isn't possible. In some ways that makes Spectre
not something you need to worry about as much, because it is unlikely that
someone would take the time to set up an exploit on such an old CPU/system.
Though if someone really wanted to target you, it is theoretically
possible. This is also why the "detection code" isn't going to improve most
likely. The only possible way to really do so is for someone to know every
CPU family/stepping/etc and basically write a table explaining whether or
not is it vulnerable. If there were a bunch of said machines in the wild,
it might be worth the effort, but I don't see CPU vendors going out of
their way on such old products. The same people who would be going through
all of those old CPU docs to write the table are still try to work on fixes
for the issues themselves.
Another issue is how the mitigation itself works. For Meltdown, it is one
solution for everything of a said arch. It can be turned on or off, and
for older atom, when those arrive it will probably have to be manually
turned off on the command line. For Spectre V1, those are simple to
mitigate, just hard to find out exaclty where, as it requires actually
auditing the code. For Spectre V2, this is all very much more complex. And
unfortunately the older the hardware, the more expensive mitigation is. Of
course all of this is done differently per arch, and sometimes even per CPU
I promise this is not some sort of conspiracy or ignoring the community.
These are all complex to mitigate, it isn't a simple "patch this hole" type
thing. There are a *lot* of people who have been working ridiculous hours
to get this done for a very long time now, and there is still a lot to do.
As you might expect, the work is mostly being done at the arch level, and
even that is happening prioritized be how many users exist. The goal being
to get the most users protected as quickly as possible. I do know there are
people working on x86 32 bit patches, but last I saw, those patches had
only been tested in a VM, and there is a good bit of QA that has to happen
at the hardware level too. As soon as those patches are ready, Fedora will
include and enable them. Luckily they also tend to have an off switch, so
if you don't think it is worth the overhead, you can turn those off.