3 ms·

No, they aren't. These mitigations are built by attempting to deny the ability to observe the side effect. This is, as this paper (and many others) show, an exe

No, they aren't. These mitigations are built by attempting to deny the ability to observe the side effect. This is, as this paper (and many others) show, an exercise in long term futility. Heck, the history of physics shows this is a long term futility (IE we've always found ways to observe things previously thought unobservable) Short term its an arms race. But you could, for example, have the JIT generate lfence everywhere and nop them out as you can prove speculation safety, for example. You could make loads/stores constant time (but with current memory technology this has higher cost than not speculating at all) There are no future magic processor bullets here. Memory instruction parallelism is the main driver of performance in most applications. Speculation of loads/stores is the one thing processors could do in cases compilers/jits/etc could not because it was assumed they could undo the side-effects (IE compilers don't do it because they fault. It was assumed processors could because they can make the fault go away. it turns out this is not the only observable side-effect, and now all the speculation they do is not really safe) Where do you go from here. Well, AFAIK, they can't make it safe to speculate like they do not in any multi-core cache coherent system that anyone has ever thought about (single core it's theoretically possible), because the side-effect is not just observable by your processor, but by the other ones. So even if your local processor could undo all the effects, because the cache is coherent, it would have already been observable to another processor and you lose again. This leaves vendors in the lurch of trying to choose between: 1. do we design cooperative software/hardware mechanisms to speculate and eat the perf cost of not speculating otherwise. 2. do we just tell everyone it's a software problem and keep on speculating everything. 3. Do we try to find an effective processor/ISA/etc abstraction that lets us speculate by default and protect the things that matter etc Nobody has any amazing ideas i've seen so far about what to do in the future. The main saving grace here is that a lot of compute bound workloads have been moving towards GPUs/etc, which generally don't do speculative execution to start (and generally are hard to observe anyway). It may in fact be that the future answer for CPUs is "stop executing speculatively, eat performance hit, accelerate move of various perf sensitive workload types to more specialized processors that use paradigms that don't have this issue"

tzs 9y ago
I may have misunderstood this, but from what I read it seems the reason Meltdown did not affect AMD is that when code running in user mode is speculatively executed it is not allowed to access kernel memory. This doesn't save AMD from Spectre because Spectre is not about bypassing hardware memory protection. It's about getting code that is allowed by the hardware to freely access certain memory but that was designed to not try to do so, to do so. So what if we added hardware memory protection that could be used by an application to protect its own memory space from itself? An application that wants to run sandboxed code could then use this to protect itself from that sandboxed code. I think we already even have a mechanism that does most of this (or at least we did up until x86 went 64-bit...I'm not sure how much of this still works in 64-bit mode): protection rings. x86 has 4 protection rings. Most operating systems only use two of them: ring 0 for the kernel, ring 3 for applications. Why not use ring 2 for applications, and ring 3 for sandboxed code running inside applications? Combine this with the x86 segmentation mechanism, which can be used to provide separate virtual address ranges within the application's virtual address space for each of the sandboxes. Even if speculation isn't fixed to respect memory protection, this could go a long way, because an instruction cannot generate an address outside of the currently mapped segments, except by first loading a new selector into the segment register, and that does a check to make sure the selector you are trying to load is for a segment that the current ring is allowed to use. I may be misremembering a lot of the details on how the rings and the segment system works, because I haven't really looked at this stuff in a very long time [1]. [1] Probably last around 1986 or so, when I was on the team at Interactive Systems that ported System V Release 3 from the 3B2 to the 386 for AT&T. I had to deal with a lot of the segment stuff back then, especially since I was half the team on the subproject to write the thing that allowed running 286 Unix and Xenix binaries on 386 Unix.
- DannyBee 9y ago
  Yes, something like this would work. Your solution is basically #1/#2 - Declaring this mostly a software problem, and giving a cooperative mechanism where software effectively marks the areas it wishes to protect. Rely on everyone to isolate everything they like, then continue speculating everything in sight and declare everyone who didn't isolate well enough to be "bad programmers" :)

tzs 9y ago

I may have misunderstood this, but from what I read it seems the reason Meltdown did not affect AMD is that when code running in user mode is speculatively executed it is not allowed to access kernel memory. This doesn't save AMD from Spectre because Spectre is not about bypassing hardware memory protection. It's about getting code that is allowed by the hardware to freely access certain memory but that was designed to not try to do so, to do so. So what if we added hardware memory protection that could be used by an application to protect its own memory space from itself? An application that wants to run sandboxed code could then use this to protect itself from that sandboxed code. I think we already even have a mechanism that does most of this (or at least we did up until x86 went 64-bit...I'm not sure how much of this still works in 64-bit mode): protection rings. x86 has 4 protection rings. Most operating systems only use two of them: ring 0 for the kernel, ring 3 for applications. Why not use ring 2 for applications, and ring 3 for sandboxed code running inside applications? Combine this with the x86 segmentation mechanism, which can be used to provide separate virtual address ranges within the application's virtual address space for each of the sandboxes. Even if speculation isn't fixed to respect memory protection, this could go a long way, because an instruction cannot generate an address outside of the currently mapped segments, except by first loading a new selector into the segment register, and that does a check to make sure the selector you are trying to load is for a segment that the current ring is allowed to use. I may be misremembering a lot of the details on how the rings and the segment system works, because I haven't really looked at this stuff in a very long time [1]. [1] Probably last around 1986 or so, when I was on the team at Interactive Systems that ported System V Release 3 from the 3B2 to the 386 for AT&T. I had to deal with a lot of the segment stuff back then, especially since I was half the team on the subproject to write the thing that allowed running 286 Unix and Xenix binaries on 386 Unix.

DannyBee 9y ago
Yes, something like this would work. Your solution is basically #1/#2 - Declaring this mostly a software problem, and giving a cooperative mechanism where software effectively marks the areas it wishes to protect. Rely on everyone to isolate everything they like, then continue speculating everything in sight and declare everyone who didn't isolate well enough to be "bad programmers" :)