Hacker News Reader

Comment by thriftwy | Hacker News Reader

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?

View on HN

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?

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.

Speculative execution, out of order execution, branch prediction have been in processor designs at least back to the 1980s.

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.)

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

[3] "math" := ZF set theory

[4] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...

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.

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.

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?

One never actually runs a Turing machine, they exist only for the purpose of argument.

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

Reply on news.ycombinator.com