18 ms·

Serious question - should we considering speculative cpu execution to be A Bad Idea (tm) and move on from it (since these problems keep coming up), or is the th

Serious question - should we considering speculative cpu execution to be A Bad Idea (tm) and move on from it (since these problems keep coming up), or is the thought that we more or less have been gaining performance on the back on incorrectly written software (which does not take these speculative execution edge cases into account), and the only forward is patching? I guess a another question I have is can we win the performance back through fixes on the cpu or will speculative execution always be insecure and thus need patching in software? Try as I might, I am not a CPU person.

shawnz 8y ago
Personally I wonder if it will ever be possible to have a platform totally free of side-channel attacks, whether or not it uses speculative execution.
- evancox100 8y ago
  No, probably not, but as with all security, electronic and otherwise, the goal is to make breaking the security cost more than whatever it's protecting is worth (for some arbitrary definitions of "cost" and "worth").
Tuna-Fish 8y ago
Completely dropping all forms of speculative execution means dropping overall performance to a tenth of today. There are really hard limits on how fast any operation, especially memory operations, can be done. The way we have made our CPUs faster is by making them do more operations in parallel, at all levels. At the lowest level, in straight line code, this very often requires speculation to achieve. Speculation is not fundamentally incompatible with security. It's just that literally everyone in the industry never though that leaking information out of speculative context was possible -- and so there is no hardening anywhere. Now that it was proven possible, people are rushing to find all the ways this can be exploited. New CPUs currently being designed will fix all these, and then eventually we will have speculation without security issues. Except for Spectre variant 1. That will always stay with us, because there is no sensible fix for it. The only real solution to that is to accept that branches cannot be used as a security boundary. This is mostly relevant to people implementing secure sandboxes and language runtimes. Going forward, the only reasonable assumption is that if you let a third party run their code in a process, no matter how you verify accesses or otherwise try to contain that code, you should assume it has a read access to the entire process. Any real security requires you to make use of the proper OS-provided isolation.
- vbezhenar 8y ago
  I wonder why do we have to rely on CPU to parallelize code. Surely compiler could do better job and CPU should just offer transistors without any smart logic. It's not backwards-compatible and I'm aware about Itanium fiasco, but I'm not compelled that it's a wrong way.
  - tylerhou 8y ago
    A quote I once heard from a friend: "Don't turn your normal problem into a distributed systems problem."
    - mokus 8y ago
      Arguably, the reason for Spectre, etc., is that people have failed to realize that at the scale of modern intel CPUs, these problems already are distributed systems problems.
  - jcranmer 8y ago
    As someone who works in compilers: no, it's not possible to make the compiler do a better job. There's a reason why VLIW architectures keep getting proposed and keep dying. The instruction-level parallelism that a CPU can extract is primarily a dynamic kind of parallelism. You can, say, have a branch that's true 1000 times, then false 1000 times, then true 1000 times, then false 1000 times, etc.--as a compiler, telling the hardware to predict true or false is going to guarantee a 50% hit rate, but the stupid simple dynamic branch predictor will get 99% on that branch.
    - kinghajj 8y ago
      What are your thoughts on the Mill CPU team's claims re: their ISA allowing compilers feasibly to schedule operations statically?
      - Taniwha 8y ago
        you can do this to some degree on most CPU's - moving loads away from their results being used - compilers, esp on RISC machines with lots of registers, do this today VLIW machines allow you to provide hints about instruction level parallelism without all the superscalar on-the-fly analysis of instruction level data dependencies (so the hardware can do all that rescheduling on the fly). I think that if interlock-free software scheduled CPUs allowed us to reach 20GHz clock speeds where complex superscalar machines were stuck at 3GHz we'd all be jumping ship - but they're not
Negitivefrags 8y ago
We can't really get rid of speculative execution, but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. It's interesting that the future predicted by excellent (and entertaining) talk The Birth & Death of Javascript [1] will now never come to pass. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- wnoise 8y ago
  > We can't really get rid of speculative execution Why not? > but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. If we accept that, then we also need to get rid of the idea that we can branch differently in trusted code based on details of "untrusted data".
  - nhaehnle 8y ago
    Your last point is basically what Spectre v1 mitigations are all about, at least if you throw in the word "speculation" somehow. The rule is: don't speculate past branches that depend on untrusted data (though there are certain additional considerations about what the speculated code would actually do). It's just that there are a lot of branches that don't depend on untrusted data. Speculatively executing past them is perfectly fine and extremely valuable for performance. That's why nobody wants to get rid of speculative execution.
    - int_19h 8y ago
      It sounds like what we really need is a memory model that reflects this notion of trusted and untrusted data. The "evil bit", basically, but for real.
niftich 8y ago
Speculative execution isn't an inherent security risk, but it typically entails a cache fill, which can, if not cleaned up or not isolated, can be used for a timing attack. That's the real issue here: that execution results in mutating a shared datastore, and facts about the likely contents of that datastore can be inferred from performing additional operations and self-measuring aspects of one's own performance. In the larger sense, mixing various privilege levels on shared hardware is likely a bad idea, despite being fundamental to general-purpose computing. This is because it's fairly difficult to cloak intrinsic "physical" attributes of execution, like execution timing, cache timing, from other processes, and essentially impossible (and/or unreasonable) to cloak it from one's own process. It is both possible for a process to generate lots of side-effects (e.g. IO, cache fill), and for it or another process to try to figure out ways the shared state changes by observing its own execution.
drb91 8y ago
From what I understand, speculative execution is “worth it” in most non secure contexts. Furthermore, it seems like one could hypothetically implement speculative execution “correctly”, where speculation is still gated by the constraints of non speculated executions. Could this be a problem that proof software could solve? I still have hope.
make3 8y ago
maybe only on things that have huge targets on their backs?

shawnz 8y ago

Personally I wonder if it will ever be possible to have a platform totally free of side-channel attacks, whether or not it uses speculative execution.

evancox100 8y ago
No, probably not, but as with all security, electronic and otherwise, the goal is to make breaking the security cost more than whatever it's protecting is worth (for some arbitrary definitions of "cost" and "worth").

Tuna-Fish 8y ago

Completely dropping all forms of speculative execution means dropping overall performance to a tenth of today. There are really hard limits on how fast any operation, especially memory operations, can be done. The way we have made our CPUs faster is by making them do more operations in parallel, at all levels. At the lowest level, in straight line code, this very often requires speculation to achieve. Speculation is not fundamentally incompatible with security. It's just that literally everyone in the industry never though that leaking information out of speculative context was possible -- and so there is no hardening anywhere. Now that it was proven possible, people are rushing to find all the ways this can be exploited. New CPUs currently being designed will fix all these, and then eventually we will have speculation without security issues. Except for Spectre variant 1. That will always stay with us, because there is no sensible fix for it. The only real solution to that is to accept that branches cannot be used as a security boundary. This is mostly relevant to people implementing secure sandboxes and language runtimes. Going forward, the only reasonable assumption is that if you let a third party run their code in a process, no matter how you verify accesses or otherwise try to contain that code, you should assume it has a read access to the entire process. Any real security requires you to make use of the proper OS-provided isolation.

vbezhenar 8y ago
I wonder why do we have to rely on CPU to parallelize code. Surely compiler could do better job and CPU should just offer transistors without any smart logic. It's not backwards-compatible and I'm aware about Itanium fiasco, but I'm not compelled that it's a wrong way.
- tylerhou 8y ago
  A quote I once heard from a friend: "Don't turn your normal problem into a distributed systems problem."
  - mokus 8y ago
    Arguably, the reason for Spectre, etc., is that people have failed to realize that at the scale of modern intel CPUs, these problems already are distributed systems problems.
- jcranmer 8y ago
  As someone who works in compilers: no, it's not possible to make the compiler do a better job. There's a reason why VLIW architectures keep getting proposed and keep dying. The instruction-level parallelism that a CPU can extract is primarily a dynamic kind of parallelism. You can, say, have a branch that's true 1000 times, then false 1000 times, then true 1000 times, then false 1000 times, etc.--as a compiler, telling the hardware to predict true or false is going to guarantee a 50% hit rate, but the stupid simple dynamic branch predictor will get 99% on that branch.
  - kinghajj 8y ago
    What are your thoughts on the Mill CPU team's claims re: their ISA allowing compilers feasibly to schedule operations statically?
    - Taniwha 8y ago
      you can do this to some degree on most CPU's - moving loads away from their results being used - compilers, esp on RISC machines with lots of registers, do this today VLIW machines allow you to provide hints about instruction level parallelism without all the superscalar on-the-fly analysis of instruction level data dependencies (so the hardware can do all that rescheduling on the fly). I think that if interlock-free software scheduled CPUs allowed us to reach 20GHz clock speeds where complex superscalar machines were stuck at 3GHz we'd all be jumping ship - but they're not

Negitivefrags 8y ago

We can't really get rid of speculative execution, but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. It's interesting that the future predicted by excellent (and entertaining) talk The Birth & Death of Javascript [1] will now never come to pass. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

wnoise 8y ago
> We can't really get rid of speculative execution Why not? > but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. If we accept that, then we also need to get rid of the idea that we can branch differently in trusted code based on details of "untrusted data".
- nhaehnle 8y ago
  Your last point is basically what Spectre v1 mitigations are all about, at least if you throw in the word "speculation" somehow. The rule is: don't speculate past branches that depend on untrusted data (though there are certain additional considerations about what the speculated code would actually do). It's just that there are a lot of branches that don't depend on untrusted data. Speculatively executing past them is perfectly fine and extremely valuable for performance. That's why nobody wants to get rid of speculative execution.
  - int_19h 8y ago
    It sounds like what we really need is a memory model that reflects this notion of trusted and untrusted data. The "evil bit", basically, but for real.

niftich 8y ago

Speculative execution isn't an inherent security risk, but it typically entails a cache fill, which can, if not cleaned up or not isolated, can be used for a timing attack. That's the real issue here: that execution results in mutating a shared datastore, and facts about the likely contents of that datastore can be inferred from performing additional operations and self-measuring aspects of one's own performance. In the larger sense, mixing various privilege levels on shared hardware is likely a bad idea, despite being fundamental to general-purpose computing. This is because it's fairly difficult to cloak intrinsic "physical" attributes of execution, like execution timing, cache timing, from other processes, and essentially impossible (and/or unreasonable) to cloak it from one's own process. It is both possible for a process to generate lots of side-effects (e.g. IO, cache fill), and for it or another process to try to figure out ways the shared state changes by observing its own execution.

drb91 8y ago

From what I understand, speculative execution is “worth it” in most non secure contexts. Furthermore, it seems like one could hypothetically implement speculative execution “correctly”, where speculation is still gated by the constraints of non speculated executions. Could this be a problem that proof software could solve? I still have hope.

make3 8y ago

maybe only on things that have huge targets on their backs?