4 ms·

Is it just me who now thinks there should be some gigantic holes in processor security, which were just never stumbled upon before, but now will? Similarly how

Is it just me who now thinks there should be some gigantic holes in processor security, which were just never stumbled upon before, but now will? Similarly how there was a long and happy life of flash plugin before it was recognized as a massive vulnerability surface?

kabes 9y ago
Well, the article ends with that same thought coming from one of the researchers.
leoc 9y ago
I'm finding it hard to escape the suspicion that Spectre and (to a lesser extent) Meltdown is another failure of expertise on the same rough scale as the run-up to the financial crisis, the decades of bad or poorly-justified dietary advice, and the statistical problems in experimental psychology. On the face of it, it seems obvious that speculation + cache + protected mode was a combination likely ripe for exploitation, but the response seems to have been "nah, it'll be fine, probably"? And even if it for some reason wasn't obvious, it's now clear that it actually was the case. So the academic and industrial and bad-boy "security community" collectively more or less let the CPU manufacturers take a flyer on this for, what, a decade?
- carlmr 9y ago
  I think this is a pervasive problem in big corporations and government. There are probably a few people that are concerned with security and others that are concerned with performance. They don't talk enough.
- graycat 9y ago
  Speculative execution, out of order execution, branch prediction have been in processor designs at least back to the 1980s.
  - leoc 9y ago
    Sure. I had Meltdown specifically on the brain when I wrote that, sorry. It hardly needs saying that the preconditions for Spectre-like attacks being around for several decades doesn't make the situation any less embarrassing. (That said, I don't know whether things like eg. increasing pipeline depths only made actual attacks feasible relatively recently.)
pdkl95 9y ago
The problem, I believe, is that most people (even many in CS/CE/EE) don't fully understand the complexity of Turing machines running programs in recursively enumerable languages. Moving a problem into software doesn't merely add complexity; it moves the problem into another class of complexity where behavior cannot be understood without running the program[1]. The behavior of sufficiently large programs (>8k states[2]) is so complex it cannot be described by math[3]. Anybody claiming to understand the consequences of adding any new feature to a processor (or software) is implicitly claiming they have solved the equivalent to halting problem. The only solution is to move as many problem as possible back to a simpler domain that is actually decidable[4]. [1] halting problem, Gödel’s Incompleteness Theorem [2] https://www.scottaaronson.com/blog/?p=2725 https://www.scottaaronson.com/blog/?p=2725 [3] "math" := ZF set theory [4] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
- msmith10101 9y ago
  Not really. That's the 'only solution' if use limit yourself to the straight jacket of existing CS theoretical methods. Given how irrelevant it has been to industry up to this point (unable to even prove something as simple to state as whether P = NP), that seems pointless.
- mannykannot 9y ago
  There are many specific Turing machines for which the behavior can be understood without running the program, such as the one that starts by unconditionally halting.
  - pdkl95 9y ago
    Are you careful to only run e.g only run javascript it's one of those special cases? How often do you use the one-state program that unconditionally halts?
    - mannykannot 9y ago
      One never actually runs a Turing machine, they exist only for the purpose of argument.

kabes 9y ago

Well, the article ends with that same thought coming from one of the researchers.

leoc 9y ago

I'm finding it hard to escape the suspicion that Spectre and (to a lesser extent) Meltdown is another failure of expertise on the same rough scale as the run-up to the financial crisis, the decades of bad or poorly-justified dietary advice, and the statistical problems in experimental psychology. On the face of it, it seems obvious that speculation + cache + protected mode was a combination likely ripe for exploitation, but the response seems to have been "nah, it'll be fine, probably"? And even if it for some reason wasn't obvious, it's now clear that it actually was the case. So the academic and industrial and bad-boy "security community" collectively more or less let the CPU manufacturers take a flyer on this for, what, a decade?

carlmr 9y ago
I think this is a pervasive problem in big corporations and government. There are probably a few people that are concerned with security and others that are concerned with performance. They don't talk enough.
graycat 9y ago
Speculative execution, out of order execution, branch prediction have been in processor designs at least back to the 1980s.
- leoc 9y ago
  Sure. I had Meltdown specifically on the brain when I wrote that, sorry. It hardly needs saying that the preconditions for Spectre-like attacks being around for several decades doesn't make the situation any less embarrassing. (That said, I don't know whether things like eg. increasing pipeline depths only made actual attacks feasible relatively recently.)

pdkl95 9y ago

The problem, I believe, is that most people (even many in CS/CE/EE) don't fully understand the complexity of Turing machines running programs in recursively enumerable languages. Moving a problem into software doesn't merely add complexity; it moves the problem into another class of complexity where behavior cannot be understood without running the program[1]. The behavior of sufficiently large programs (>8k states[2]) is so complex it cannot be described by math[3]. Anybody claiming to understand the consequences of adding any new feature to a processor (or software) is implicitly claiming they have solved the equivalent to halting problem. The only solution is to move as many problem as possible back to a simpler domain that is actually decidable[4]. [1] halting problem, Gödel’s Incompleteness Theorem [2] https://www.scottaaronson.com/blog/?p=2725 https://www.scottaaronson.com/blog/?p=2725 [3] "math" := ZF set theory [4] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...

msmith10101 9y ago
Not really. That's the 'only solution' if use limit yourself to the straight jacket of existing CS theoretical methods. Given how irrelevant it has been to industry up to this point (unable to even prove something as simple to state as whether P = NP), that seems pointless.
mannykannot 9y ago
There are many specific Turing machines for which the behavior can be understood without running the program, such as the one that starts by unconditionally halting.
- pdkl95 9y ago
  Are you careful to only run e.g only run javascript it's one of those special cases? How often do you use the one-state program that unconditionally halts?
  - mannykannot 9y ago
    One never actually runs a Turing machine, they exist only for the purpose of argument.