This issue was discovered independently by several groups, and on multiple continents.
Google is one, but a number of European universities and other companies (even Rambus, who is somehow still around) have been involved too.
ARM has probably been one of the best reactions that I've seen, being far more thorough and writing far more about which of their processor designs are affected, and by how much.
According to Red Hat, spectre has been found to affect the Power 8 and Power 9 architectures.
Apple has a press release stating that all of its ARM-powered iOS devices are affected in addition to every Mac.
Xensource wants Xen to work everywhere, and they've been thorough in documenting and testing - and they've replicated spectre with ARM, Intel, and even AMDâ(TM)s latest processors. They have promised more details as the embargo is lifted.
It's not a conspiracy to smear AMD or anyone else.
They're security professionals who are concerned with keeping everyoneâ(TM)s computer secure.
MIPS isn't quite dead - and its grandson, RISC-V, is starting to get traction (with NVIDIA adopting it, among others), and has nacent support in the Linux Kernel.
But what's one new architecture compared to the 3 or 4 that will have died in the same period of time?
Intel's PR department is so deep in CYA territory they probably don't know what the truth is, let alone how to tell it.
Today's press release is much more slimy than yesterday's; yesterday Intel mentioned (and thanked) AMD and ARM for their contributions in identifying and mitigating the issue. Today... not so much.
It's also misleading to say Intel doesn't have engineers providing patches. I've worked with more than a few Intel FAE's (Field Application Engineers) in the past - Intel literally flies their engineers to help partners.
The thing to look for is "PCID" instruction support. Intel CPU's without the PCID instruction are slowed more than those that have it.
I've done some looking at various machines at work, home, etc, and have found a Broadwell Xeon E3-1276 that has the PCID instruction but the older Ivy Bridge doesn't. (And I'm sure the PCID support also depends on the model of the CPU -- maybe Xeon has it while i7 doesn't)
The mitigations for the "Meltdown" bug affect context-switching most: So an application that hits the disk with many small requests, and/or hits the network with many small requests (such a Database does both) will be heavily affected.
Games typically don't hit the disk very hard outside "Loading screens", which means they won't suffer as much on that front.
Online games do hit the network (and have more context switches); single player games don't - so YMMV depending on your game.
I doubt it's so much that Intel doesn't care about hardware older than 5 years, so much as they're prioritizing newer hardware. (Supporting older hardware rapidly reaches the point of diminishing returns).
I'm pretty sure my 2007-era Core2 MacBook will never see a fix from Apple or Intel. I could probably "get" a patched OS on it by switching to Linux... but it's easier for me to put the MacBook out to pasture and use my Raspberry Pi 3 instead.
Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap
It actually might: many makers (<cough>Apple</cough>) only buy Intel chips, and I wouldn't be surprised if a lot of folks buy a new computer in the (mistaken) belief that will have an updated CPU that fixes the bug.
Few consumers understand the lead time for hardware to go from an engineer's workstation to fabricated hardware. I wouldn't expect an Intel chip that won't "Meltdown" until 2019 at the earliest.
That's why the Intel boss sold his shares in time
The problem (for the prosecutor) is proving to the Jury that it was insider trading. (And that's of course the problem with a lot of criminal justice: Just because you know something doesn't mean you can prove it.)
Intel's stock skyrocketed on October 26th, and then slowly fell from Nov 2 to Dec 15th. So if Intel's CEO sold his stock on, say, Nov 3rd, it'll be a tough sell to say he wasn't just "selling high."
We can't even design a car with a few thousand parts that doesn't have unintended side effects.
The idea a machine with billions of transistors won't have unintended side effects is comical at best.
Processor eratta are maintained by every chip maker -- from the lowliest 4-bit microcontroller all the way up to beasts like Ryzen. This particular problem just happens to be unusually bad, and in a place that can't be fixed with microcode.
Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations.
I'd caution against a false sense of security, based on one's choice of processor for your personal desktop.
There's no disagreement that "Meltdown" is the greater problem, and affects pretty much any Intel chip still functioning. It's important to remember that it's virtually guaranteed that connect to many servers that uses an affected processor every day. Those of us who maintain cloud infrastructures are particularly unhappy with the situation.
The fact that Meltdown is worse shouldn't distract from the fact that Spectre is bad.
The paper on Spectre is written by a number of people working for a number of organizations, but Intel isn't one of them. It has the following statement:
We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones
They go on to state they've verified the weakness on x86 using C and JavaScript (+ Google V8 JIT) bytecode.
Much like JavaScript cryptocurrency mining , the fact that something is hard doesn't mean it's not worth doing to those interested, and having browser-based JavaScript exposing data isn't a good thing.
Meltdown can be fixed fairly easily (AMD certainly shows it's possible to avoid the problem). Spectre, however, will be with us for a long time.
Cross privilege boundaries means that userspace can cross into kernelspace unchecked. That's of course, a worst case scenario.
The lesser variant means that all of userspace is compromised, as userspace programs donâ(TM)t need to swap to a different protection ring.
This has huge implications in hypervisor environments where the VMâ(TM)s kernel is also running in userspace).
Itâ(TM)s not exactly âoegood newsâ for those of us with large virtual machine infrastructures, because it means any process on the VM can conceivably read the kernelâ(TM)s memory, as well as the memory in another VM.
Docker containers are even more vulnerable.
And, letâ(TM)s not forget your SSH keys (or browserâ(TM)s SSL/TLS session keys) are also in userspace memory, which is compromised.
As an aside, AMDâ(TM)s Opteron-A is Cortex-A57 design, which ARM explicitly states is vulnerable to 3 out of 4 variants of the bug in their press release. Iâ(TM)ve heard Google's Project Zero released more details too (sorry, no link, I haven't read it yet).
Intel is still being a weasel in their press release, of course.
Slashdot Mirror
This issue was discovered independently by several groups, and on multiple continents.
Google is one, but a number of European universities and other companies (even Rambus, who is somehow still around) have been involved too.
ARM has probably been one of the best reactions that I've seen, being far more thorough and writing far more about which of their processor designs are affected, and by how much.
According to Red Hat, spectre has been found to affect the Power 8 and Power 9 architectures.
Apple has a press release stating that all of its ARM-powered iOS devices are affected in addition to every Mac.
Xensource wants Xen to work everywhere, and they've been thorough in documenting and testing - and they've replicated spectre with ARM, Intel, and even AMDâ(TM)s latest processors. They have promised more details as the embargo is lifted.
It's not a conspiracy to smear AMD or anyone else.
They're security professionals who are concerned with keeping everyoneâ(TM)s computer secure.
A minor follow up: the Apple statement where they admit all iOS devices are affected.
(And Macs, but we knew that already)
MIPS isn't quite dead - and its grandson, RISC-V, is starting to get traction (with NVIDIA adopting it, among others), and has nacent support in the Linux Kernel.
But what's one new architecture compared to the 3 or 4 that will have died in the same period of time?
You're totally right; I misread the table -- the G34 socket and Opteron 6300 is a Piledriver chip, not Ryzen.
AMD Epyc the new brand name that replaces AMD's Opteron server line (can I say I hate rebranding?)
It's the Epyc 7551 is ZEN architecture, uses the SP3 LGA socket, and has 32 cores/64 threads.
SuperMicro appears to have some in the pipeline, and even has a dual-socket model, with IPMI 2.0.
128 threads in a single system ain't too shabby...
amd ThreadRipper same thing no IPMI and no workstation boards.
The ThreadRipper Opteron 6300 is a socket G34 board.
NewEgg has Dual-Socket G34 boards, designed for workstations and server racks.
It can use an embedded KVM for remote management, which is an IPMI 2.0 compliant interface.
So... go vote with your wallet or something.
Should we be surprised when this obfuscates access to their management engine.
Access to their management engine was already obfuscated, and we've been clamoring for clarity.
Intel's PR department is so deep in CYA territory they probably don't know what the truth is, let alone how to tell it.
Today's press release is much more slimy than yesterday's; yesterday Intel mentioned (and thanked) AMD and ARM for their contributions in identifying and mitigating the issue. Today... not so much.
It's also misleading to say Intel doesn't have engineers providing patches. I've worked with more than a few Intel FAE's (Field Application Engineers) in the past - Intel literally flies their engineers to help partners.
Intel's has long had engineers working on the Linux kernel, and did in fact contribute patches for KPTI (ie. "meltdown"), so we know they've helped patch the Linux Kernel.
The thing to look for is "PCID" instruction support. Intel CPU's without the PCID instruction are slowed more than those that have it.
I've done some looking at various machines at work, home, etc, and have found a Broadwell Xeon E3-1276 that has the PCID instruction but the older Ivy Bridge doesn't. (And I'm sure the PCID support also depends on the model of the CPU -- maybe Xeon has it while i7 doesn't)
The mitigations for the "Meltdown" bug affect context-switching most: So an application that hits the disk with many small requests, and/or hits the network with many small requests (such a Database does both) will be heavily affected.
Games typically don't hit the disk very hard outside "Loading screens", which means they won't suffer as much on that front.
Online games do hit the network (and have more context switches); single player games don't - so YMMV depending on your game.
I doubt it's so much that Intel doesn't care about hardware older than 5 years, so much as they're prioritizing newer hardware. (Supporting older hardware rapidly reaches the point of diminishing returns).
I'm pretty sure my 2007-era Core2 MacBook will never see a fix from Apple or Intel. I could probably "get" a patched OS on it by switching to Linux... but it's easier for me to put the MacBook out to pasture and use my Raspberry Pi 3 instead.
I think we can safely say that if people haven't switched from XP by now, there's nothing in Meltdown or Spectre that'll change their minds.
Phoronix did a few benchmarks on games
Of course, each game is a different animal, but it looks like there may be reason to hope that games aren't heavily affected.
In any case all these bugs seem fairly theoretically and very difficult to be actually exploited.
The Spectre paper documents a proof of concept in five lines of JavaScript code that works on Google's V8 JavaScript engine (ie. Google Chrome).
That doesn't appear to be merely theoretical.
The paper also appears to insinuate that RISC-V and MIPS might be vulnerable as well.
RISC-V is so new it's not widely deployed, but MIPS... well, that's in most routers.
LWN published articles indicating a problem back in November, and followed up on it a number of times.
That the Kernel devs would prioritize a fairly invasive patch set, reducing performance up to 30% was a sign that something was amiss.
The fact the LKML had practically no discussion for why so much effort was being expended on it was a sign that something was very, very wrong.
Yes, it really boosts your sales, especially internationally, when the press tells everyone your CPUs are insecure crap
It actually might: many makers (<cough>Apple</cough>) only buy Intel chips, and I wouldn't be surprised if a lot of folks buy a new computer in the (mistaken) belief that will have an updated CPU that fixes the bug.
Few consumers understand the lead time for hardware to go from an engineer's workstation to fabricated hardware. I wouldn't expect an Intel chip that won't "Meltdown" until 2019 at the earliest.
That's why the Intel boss sold his shares in time
The problem (for the prosecutor) is proving to the Jury that it was insider trading. (And that's of course the problem with a lot of criminal justice: Just because you know something doesn't mean you can prove it.)
Intel's stock skyrocketed on October 26th, and then slowly fell from Nov 2 to Dec 15th. So if Intel's CEO sold his stock on, say, Nov 3rd, it'll be a tough sell to say he wasn't just "selling high."
Best of luck to the DA investigating, though.
Hanlon's rasor applies pretty well here.
We can't even design a car with a few thousand parts that doesn't have unintended side effects.
The idea a machine with billions of transistors won't have unintended side effects is comical at best.
Processor eratta are maintained by every chip maker -- from the lowliest 4-bit microcontroller all the way up to beasts like Ryzen. This particular problem just happens to be unusually bad, and in a place that can't be fixed with microcode.
Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations.
I'd caution against a false sense of security, based on one's choice of processor for your personal desktop.
There's no disagreement that "Meltdown" is the greater problem, and affects pretty much any Intel chip still functioning. It's important to remember that it's virtually guaranteed that connect to many servers that uses an affected processor every day. Those of us who maintain cloud infrastructures are particularly unhappy with the situation.
The fact that Meltdown is worse shouldn't distract from the fact that Spectre is bad.
The paper on Spectre is written by a number of people working for a number of organizations, but Intel isn't one of them. It has the following statement:
We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones
They go on to state they've verified the weakness on x86 using C and JavaScript (+ Google V8 JIT) bytecode.
Much like JavaScript cryptocurrency mining , the fact that something is hard doesn't mean it's not worth doing to those interested, and having browser-based JavaScript exposing data isn't a good thing.
Meltdown can be fixed fairly easily (AMD certainly shows it's possible to avoid the problem). Spectre, however, will be with us for a long time.
Cross privilege boundaries means that userspace can cross into kernelspace unchecked. That's of course, a worst case scenario.
The lesser variant means that all of userspace is compromised, as userspace programs donâ(TM)t need to swap to a different protection ring.
This has huge implications in hypervisor environments where the VMâ(TM)s kernel is also running in userspace).
Itâ(TM)s not exactly âoegood newsâ for those of us with large virtual machine infrastructures, because it means any process on the VM can conceivably read the kernelâ(TM)s memory, as well as the memory in another VM.
Docker containers are even more vulnerable.
And, letâ(TM)s not forget your SSH keys (or browserâ(TM)s SSL/TLS session keys) are also in userspace memory, which is compromised.
As I read it, best case, all of userland is compromised. Worst case, both userland *and* the kernel are compromised.
Weâ(TM)ve all found ourselves in the middle of a pool of shit thatâ(TM)s deeper in some places than others.
The fact AMDâ(TM)s x86 offering are in a more shallow part doesnâ(TM)t make their end of the pool any more appealing to swim in.
Perhaps ARM's press release detailing the ten affected ARM Cortex designs may convince you?
The Opteron-A is an ARM Cortex A57 design, and is vulnerable to three of the four variants of this bug.
ARM's own press release on the issue.
10 of the ARM Cortex designs are affected to some extent.
I managed to find ARM's press release.
As an aside, AMDâ(TM)s Opteron-A is Cortex-A57 design, which ARM explicitly states is vulnerable to 3 out of 4 variants of the bug in their press release. Iâ(TM)ve heard Google's Project Zero released more details too (sorry, no link, I haven't read it yet).
Intel is still being a weasel in their press release, of course.
https://developer.arm.com/supp...
How about ARMâ(TM)s own How about ARMâ(TM)s own press release and white paper?
For the record, AMDâ(TM)s Opteron-A is a Cortex A57 design, which is affected.
Read ARMâ(TM)s own statement.
They list four variants of vulnerability, and includes the following ARM cortex designs:
* R7
* R8
* A8
* A9
* A15
* A17
* A57 (Includes AMDâ(TM)s Opteron-A)
* A72
* A73
* A75
So go look at ARMâ(TM)s document, and read their white paper. As ARM claims many of their designs have this bug, Iâ(TM)m inclined to believe them.