5 ms·

> This exploit is very hard to imagine before now. It's really not. It's the sort of thing you wonder after first learning about out-of-order and speculative e

> This exploit is very hard to imagine before now. It's really not. It's the sort of thing you wonder after first learning about out-of-order and speculative execution in a computer architecture class, but your professor assures you that implementors have been very careful to ensure any partial execution is properly flushed and rolled back. Then it turns out that, nope, no one's actually been keeping an eye on this after all.

laurencei 9y ago
...but if it is "so obvious" - why has it taken ~20 years to discover it (publically)?
- crankylinuxuser 9y ago
  Because like most inventions, its obvious after the fact. But getting there was time-intensive and wrought with many ways of failure.
- brians 9y ago
  It’s been discussed for years by people who didn’t need to see the exploit to know that it had to be there. Sane people have been avoiding timesharing for critical work on x86 since Core 2. Life-safety work has no business in a public cloud.
  - carapace 9y ago
    This is a recurring pattern that just blows my mind: typically some small, often academic, group knows about some problem or potential problem that everybody else is ignoring until it becomes un-ignorable. Anthopogenic climate change falls into this category. I have to wonder, first, what sort of obvious stupid self-destructive things am I doing right now but ignoring. And second, how can we build systems that systematically take this into account? Is there some way to short-cut the process and find and fix problems in the early stages? Or better yet, design our systems so that they don't have the problems from the start?
    - Strom 9y ago
      The key thing to take into account here is that for every one of those early warnings that turn out to be true there's also a plethora of speculation that never amounts to anything.
    - mannykannot 9y ago
      It is not really comparable to climate change - people have been assuming that everything is OK, but there is no well-organized campaign to persuade people that these exploits don't exist now there is good evidence that they do. There is one attitude that exacerbates those problems that are real - the tacit assumption that concerns do not count for anything until an exploit has been demonstrated.
pwg 9y ago
> but your professor assures you that implementors have been very careful to ensure any partial execution is properly flushed and rolled back. And, at the time, your professor was correct, to the extent of what he/she defined as "any partial execution". But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and the flags register). Their definition ignored the cache, because at the time the cache was considered simply a transparent optimization system that did not effect the values of contents of the CPU architectural state. And in a way, that definition is still valid, even after the knowledge of these exploits. The CPU architectural state (registers/flags), even after executing exploit code, is exactly what it would have been had sequential execution happened. The exploit takes advantage of the fact that you can arrange the right set of code to run just the right way to leave a different state in the _cache_ (i.e., that thing believed to have been merely a transparent optimization). It turns out now that the belief in the cache being transparent and only providing optimizations was the flaw in the belief system at the time.
- mintplant 9y ago
  > But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and the flags register). Their definition ignored the cache, because at the time the cache was considered simply a transparent optimization system that did not effect the values of contents of the CPU architectural state. You're putting words in other people's mouths here.

laurencei 9y ago

...but if it is "so obvious" - why has it taken ~20 years to discover it (publically)?

crankylinuxuser 9y ago
Because like most inventions, its obvious after the fact. But getting there was time-intensive and wrought with many ways of failure.
brians 9y ago
It’s been discussed for years by people who didn’t need to see the exploit to know that it had to be there. Sane people have been avoiding timesharing for critical work on x86 since Core 2. Life-safety work has no business in a public cloud.
- carapace 9y ago
  This is a recurring pattern that just blows my mind: typically some small, often academic, group knows about some problem or potential problem that everybody else is ignoring until it becomes un-ignorable. Anthopogenic climate change falls into this category. I have to wonder, first, what sort of obvious stupid self-destructive things am I doing right now but ignoring. And second, how can we build systems that systematically take this into account? Is there some way to short-cut the process and find and fix problems in the early stages? Or better yet, design our systems so that they don't have the problems from the start?
  - Strom 9y ago
    The key thing to take into account here is that for every one of those early warnings that turn out to be true there's also a plethora of speculation that never amounts to anything.
  - mannykannot 9y ago
    It is not really comparable to climate change - people have been assuming that everything is OK, but there is no well-organized campaign to persuade people that these exploits don't exist now there is good evidence that they do. There is one attitude that exacerbates those problems that are real - the tacit assumption that concerns do not count for anything until an exploit has been demonstrated.

pwg 9y ago

> but your professor assures you that implementors have been very careful to ensure any partial execution is properly flushed and rolled back. And, at the time, your professor was correct, to the extent of what he/she defined as "any partial execution". But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and the flags register). Their definition ignored the cache, because at the time the cache was considered simply a transparent optimization system that did not effect the values of contents of the CPU architectural state. And in a way, that definition is still valid, even after the knowledge of these exploits. The CPU architectural state (registers/flags), even after executing exploit code, is exactly what it would have been had sequential execution happened. The exploit takes advantage of the fact that you can arrange the right set of code to run just the right way to leave a different state in the _cache_ (i.e., that thing believed to have been merely a transparent optimization). It turns out now that the belief in the cache being transparent and only providing optimizations was the flaw in the belief system at the time.

mintplant 9y ago
> But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and the flags register). Their definition ignored the cache, because at the time the cache was considered simply a transparent optimization system that did not effect the values of contents of the CPU architectural state. You're putting words in other people's mouths here.