5 ms·

Halfway through he notes how processors have millions of transistors, each being slightly different, and notes how we are just soooo lucky to have found a hardw

by tomc1985 9y ago

Halfway through he notes how processors have millions of transistors, each being slightly different, and notes how we are just soooo lucky to have found a hardware bug now. Except both Spectre and Meltdown, AFAIK (IANAHWE) are design flaws as the silicon is working as intended. The hardware is fine -- the real problem is that the Intel's reputation is partially built on speed, and, now that the cladding has fallen off, we've discovered the platform was built with really flimsy supports.

samstave 9y ago
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"
- steiger 9y ago
  Intel valued speed optimizations that are inherently insecure.
  - deleted 9y ago
    [deleted]
  - samstave 9y ago
    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)
- username223 9y ago
  > 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.
  - rayiner 9y ago
    “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.
    - pdpi 9y ago
      Speculative execution modifies observable state. What you call it is imaterial.
      - rayiner 9y ago
        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.
      - dfox 9y ago
        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.
      - mannykannot 9y ago
        '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.
    - gjjfdg 9y ago
      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.
- tomc1985 9y ago
  I am referring to their flawed implementation of speculative execution, with respect to how much of today's CPU performance is due to it.
monocasa 9y ago
IDK, I think there's a way to have your cake and eat it too WRT chip level optimizations. For instance brushing off rings 1 and 2 from the dust bin of history could give user and kernel code ways to describe multiple levels of memory protection in a way that the chip can understand. That way, the same way that AMD was protected from Meltdown ("I can tell from the TLB that address is outside of what this code is supposed to touch, so I'm not going to speculate past that") could be expanded to a more general form.
- tomc1985 9y ago
  I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad?
  - monocasa 9y ago
    > I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? It's all either ring 3 (user) or ring 0 (kernel) for the purposes of this discussion. The biggest architectural impediment is the single bit for ring selection in page table entries. And since long mode requires paging, there's currently not a way to select rings 1 and 2. Although you might be able to play with some of the hypervisor extensions to give you guest ring 0 context inside a regular user process... See Akaros for a good example of what that looks like. > Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? Because the cache is a fixed size, and that just kicks the can down the road. You'll just test for the eviction in your exploit instead.
  - deleted 9y ago
    [deleted]
  - CamperBob2 9y ago
    If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? "Clearing the cached data" is just as detectable as caching the data in the first place. You'd have to treat the line fill as a transaction that could be rolled back. Unfortunately, transactional memory and CPU caches lie at polar-opposite ends of the performance spectrum.
avianlyric 9y ago
> Halfway through he notes how processors have millions of transistors, each being slightly different, and notes how we are just soooo lucky to have found a hardware bug now. I read that as the other way around. He says: > We should all be more surprised that it took so long for a major hardware bug to be found, than the fact that one was ever found. Which I would read as, "it's surprising we don't discover bugs in hardware more often". I would also say, that in the world of embedded devices, HW bugs in silicon are the norm, and your chips come with some form of errata.
- monocasa 9y ago
  And it's not just embedded devices. AMD and Intel put out tons of errata too.
MaxBarraclough 9y ago
> Intel's reputation is partially built on speed Except the Spectre vulnerability isn't specific to Intel's chips.

samstave 9y ago

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"

steiger 9y ago
Intel valued speed optimizations that are inherently insecure.
- deleted 9y ago
  [deleted]
- samstave 9y ago
  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)
username223 9y ago
> 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.
- rayiner 9y ago
  “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.
  - pdpi 9y ago
    Speculative execution modifies observable state. What you call it is imaterial.
    - rayiner 9y ago
      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.
    - dfox 9y ago
      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.
    - mannykannot 9y ago
      '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.
  - gjjfdg 9y ago
    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.
tomc1985 9y ago
I am referring to their flawed implementation of speculative execution, with respect to how much of today's CPU performance is due to it.

monocasa 9y ago

IDK, I think there's a way to have your cake and eat it too WRT chip level optimizations. For instance brushing off rings 1 and 2 from the dust bin of history could give user and kernel code ways to describe multiple levels of memory protection in a way that the chip can understand. That way, the same way that AMD was protected from Meltdown ("I can tell from the TLB that address is outside of what this code is supposed to touch, so I'm not going to speculate past that") could be expanded to a more general form.

tomc1985 9y ago
I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad?
- monocasa 9y ago
  > I didn't even know rings 1 and 2 were even relegated to the dustbin.... so everything is ring 0 now?? It's all either ring 3 (user) or ring 0 (kernel) for the purposes of this discussion. The biggest architectural impediment is the single bit for ring selection in page table entries. And since long mode requires paging, there's currently not a way to select rings 1 and 2. Although you might be able to play with some of the hypervisor extensions to give you guest ring 0 context inside a regular user process... See Akaros for a good example of what that looks like. > Which brings me to another something I don't understand about this. If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? Because the cache is a fixed size, and that just kicks the can down the road. You'll just test for the eviction in your exploit instead.
- deleted 9y ago
  [deleted]
- CamperBob2 9y ago
  If mispredictions leave their calculations in cache why can't that cached data be cleared after the branch is determined to be bad? "Clearing the cached data" is just as detectable as caching the data in the first place. You'd have to treat the line fill as a transaction that could be rolled back. Unfortunately, transactional memory and CPU caches lie at polar-opposite ends of the performance spectrum.

avianlyric 9y ago

> Halfway through he notes how processors have millions of transistors, each being slightly different, and notes how we are just soooo lucky to have found a hardware bug now. I read that as the other way around. He says: > We should all be more surprised that it took so long for a major hardware bug to be found, than the fact that one was ever found. Which I would read as, "it's surprising we don't discover bugs in hardware more often". I would also say, that in the world of embedded devices, HW bugs in silicon are the norm, and your chips come with some form of errata.

monocasa 9y ago
And it's not just embedded devices. AMD and Intel put out tons of errata too.

MaxBarraclough 9y ago

> Intel's reputation is partially built on speed Except the Spectre vulnerability isn't specific to Intel's chips.