Hacker News Reader

Comment by samstave | Hacker News Reader

Can you please unpack "really flimsy supports" in ELI5 language? I dont get that part of your comment - though I was surprised IN understood your "I am not a hardware engineer" fluidly...

But define "flimsy supports"

View on HN

> Can you please unpack "really flimsy supports" in ELI5 language?

Modern CPUs rely upon "speculative execution" for speed, i.e. running code that they guess will be run. This usually works, but relies upon the CPU getting rid of the results of its incorrect guesses. Intel CPUs failed to do this in a very obvious way, which was recently exploited. As a result, they broke software security checks.

EDIT: Let's say your code is

    if (security_check()) {
      secure_stuff();
    } else {
      error();
    }

The Intel CPU may guess that security_check() will return true, and run secure_stuff(). When security_check() actually returns false, it doesn't clean up all of the results of running secure_stuff(), so error() can spy on what it would have done if security_check() returned true.

“Results” is a loaded term. In computation, “results” means the return value of a computation. Intel does keep you from observing the result of secure_stuff. What it doesn’t do is clean up all the side effects.

Speculative execution modifies observable state. What you call it is imaterial.

Words have meaning. The “result” of a computation is different from side effects. The distinction is important. Speculative execution will always modify “observable state.” E.g. power usage.

The point there is that what spectre/meltdown exploits are sideffects that are not part of the architectural state as it is specified by any manufacturer. The whole issue points to the fact that security-wise the typical approach used for descriptions of CPU's architectural behavior is insufficient as there can be implementation-specific observable sideeffects that have security ramifications.

'Results' and 'side-effects' are useful modifiers of 'modifies observable state', and the long-overlooked fact that the latter falls into the category is an important insight. I think you would find it very difficult to explain the problem or discuss possible solutions without making additional distinctions, beyond 'modifies observable state', with regard to what speculative execution does.

ELI5 is an internet acronym for "Explain like I'm five (years old)". In this example, "secure_stuff" may well be a call to a function that does not return any value. Some functions are like that. But if it isn't, we no longer are sure that the code in the else branch of the loop won't be able to deduce what would be returned as the result, thanks to Intel, no thanks to Intel.

Shame on you.

Personal attacks are not allowed on HN and we ban accounts that do this. Please post civilly and substantively, or not at all.

https://news.ycombinator.com/newsguidelines.html

Intel valued speed optimizations that are inherently insecure.

ah.

Hmm.

I worked at intel in the 90s... Ran the game lab - when they came out with the Celeron, they created SIMD instructions - and they paid (bribed) game companies to optimize their games against the instruction set - fofr $1MM in marketing bonuses.... (i.e. "play gameX on intels celeron based PCs and achieve X% performance gain")

And all of this was to prove that they could produce a <$1,000 machine that a consumer would want (the basis of the celeron proc)

I am referring to their flawed implementation of speculative execution, with respect to how much of today's CPU performance is due to it.

Reply on news.ycombinator.com