What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…
> Stop buying Intel products, and devices which contain them?
None of that helps with your public cloud workloads.
Sorry for being naive. Are these kind of CPU Securities vulnerabilities new? Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months. And as far as I am aware they are mostly Intel CPU only. Why? And Why not AMD? Something in the Intel design process went wrong? And yet all the Cloud Vendor…
A lot of reasons - one, we only recently (in academic research time) started using single servers to host services from multiple customers, so the value of these sorts attacks only recently became apparent. Second, as I understand it, Spectre and Meltdown really started this whole parade because prior to those vulnerabilities, speculative execution attacks were something only academics ever talked about - everyone as…
Dan Luu didn't note that Meltdown goes all the way back to their first out-of-order speculative execution design, the Pentium Pro in 1995. I note that ARM, and both of IBM's architectures, POWER and mainframe, also had Meltdown issues, and everyone including AMD "enjoys" Spectre bugs, so named because they'll be haunting us for a very long time.
What impact does this have in a multi-tenant cloud environment? I'm legitimately considering moving my security critical EC2 instances over to AMD-backed instance types right now.
I'm not a security person but I wanna practice trying to sum up his points: 1. There's no way in hell that a bunch of VMs running on one physical server is more secure than a bunch of different physical servers each running an OS. If there were architectural hooks for those VMs to provide additional security beyond what the host OS provides, then an OS like OpenBSD would already be making use of it. 2. Running a bunc…
I think the argument VM-sellers make is that it's more secure than running a bunch of colocated code on the same machine without VMs, not that it's more secure than distinct physical systems.
That is their claim. Theo is pointing out that the security is an illusion. Either the OS is secure and so you may as well just run everything in the OS without the VM in the way (ignoring issues of different operating system), or the OS is not secure and now you have to hope the VM is secure because otherwise you just exploit your VM to get out of it and then exploit the OS. The second level attack is more difficult, but that is all.
What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…
The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution , not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates…
What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…
Step one: switch to in-order cores. Step two: cheekily author a Medium article titled Tomasulo's Algorithm Considered Harmful
The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution , not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates…
That's not exactly true. Broadly speaking, there have been two very different kinds of speculative execution vulnerabilities with different security implications and workarounds. Spectre and its relatives are an attack on trusted code that process untrusted data using certain code patterns guarded by conditionals that can be speculatively executed; they're inherent to speculative execution past branches, but they req…
Yes, that's true, several of the vulnerabilities involve checks that are performed late (not at time of speculative access, but at some point before instruction commit). Not excusing the design choice at all, but it's conceivable that an engineer could make this choice if (i) side-channel effects of the speculation are not considered at all, and (ii) the postponement of the check allows the load latency to be reduced. Again, not justifying, and the vulnerabilities are terrible, but there does seem to be a rational-given-some-assumptions way to reach such a decision.
Not necessarily. This is more like Meltdown in that it involves one context just outright accessing data in a completely different context, and AMD chips seem to be totally immune from that attack. Any chip with a microarchitecture that actually enforces the architecturally-guaranteed checks, rather than ignoring them and fixing the results up later, can avoid such attacks. Spectre, on the other hand, is harder both…
> This is more like Meltdown in that it involves one context just outright accessing data in a completely different context, and AMD chips seem to be totally immune from that attack. No, AMD has been largely immune to bugs involving speculating past a page fault . Both Meltdown and L1TF involved speculating past page faults, and the ZombieLoad paper also mentions exploiting bad behavior during page faults (but, discl…
Spectre variant 2 was a little more interesting in that it can trick the processor into speculative execution of something that's not a valid execution path for the victim context (by confusing it about the target of an indirect branch), but it still relies on the speculative execution happening in a context that is meant to have access to the targetted data. It's sort of halfway between this and the other Spectre variants; it can be fixed in hardware or software.
All three of these latest vulnerabilities are like Meltdown and L1TF in that they just allow speculative execution to completely ignore hardware-level access protections and read data from a completely different process, and there's nothing that can be done about it at the software level. (Originally, the comment you're replying to was posted on a discussion about all three, if I remember rightly.) All of these affect Intel but not AMD. It's not like modern AMD chips are exactly poor performers either.
The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution , not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates…
In-order does not mean no speculative execution
Yes, but it typically means a significantly smaller speculative window -- rather than a ROB that can fill with several hundred instructions beyond a mispredicted branch, there is just the pipeline depth from fetch to commit worth of speculative work.