5 ms·

Is it even possible to design a cpu with out-of-order and speculative execution that would have no security issue? Is the future leads to a swarm of disconnecte

by bobim 3y ago

Is it even possible to design a cpu with out-of-order and speculative execution that would have no security issue? Is the future leads to a swarm of disconnected A55 cores each running a single application?

SmoothBrain12 3y ago
Yes, but they won't clock as fast because they'll be waiting for RAM.
- bobim 3y ago
  We need to keep programs small so they fit in the cache.
  - moffkalast 3y ago
    We need 2 GBs of L1 cache, thus solving the cache miss problem once and for all.
    - rep_lodsb 3y ago
      640K should be enough for anyone ;)
Tuna-Fish 3y ago
This vulnerability was not caused by OoO or speculative execution. It was caused by the fact that x86 was designed 45 years ago, and has had feature after feature piled on the same base, which has never been adequately rebuilt. The more proximate cause is that some instructions with multiple redundant prefixes (which is legal, but pointless) have their length miscalculated by some Intel CPUs, which results in wrong outcomes.
- epcoa 3y ago
  Not entirely pointless, redundant prefixes are occasionally the useful method for alignment.
  - TheCoreh 3y ago
    A more sensible approach for that use-case would be IMO to have well-defined specialized prefixes for padding, instead of relying on the case-by-case behavior of redundant prefixes. (However I understand that there's almost certainly a good historical reason why this was not the way it was done)
    - bobim 3y ago
      Are new ISA solving this? Time to move to Risc V?
      - epcoa 3y ago
        N/A and No.
      - dontlaugh 3y ago
        RISC V is not great at this either, with the compression extension being common and variable length. ARM 64 gets this right, with fixed length 32 bit instructions.
        snvzz 3y ago
        >ARM 64 gets this right, with fixed length 32 bit instructions. At the expense of code density, yet RISC-V is easy to decode, with implementations going up to 12-way decode (Veyron V2) despite variable length. ARM64 hardly "gets it right".
        camel-cdr 3y ago
        I wouldn't say ARM64 gets it wrong either, I think both are viable approaches.
- gumby 3y ago
  > It was caused by the fact that x86 was designed 45 years ago, and has had feature after feature piled on the same base, which has never been adequately rebuilt. Itanic would like to object! Unfortunately it can’t get through the door.
nextaccountic 3y ago
I think formal methods could help designing of such machine, if you can write a mathematical statement that amounts to "there is no side channel between A and B" Or at least put a practical bound on how many bits per second at most you can from any such side channel (the reasoning being, if you can get at most a bit for each million years, you probably don't have an attack) Then you verify if a given design meets this constraint
- mgaunard 3y ago
  A program is itself a formal specification of what an algorithm does.
  - kiitos 3y ago
    Programs are implementations of specifications, they're not specifications themselves. Unless you're talking about like Coq or TLA+.
- bobim 3y ago
  What would be the typical size of such a constraint-based problem, and do we have the compute power to translate the rules into an implementation? And what if one forgot a rule somewhere… Deeply interesting subject.
  - less_less 3y ago
    I think you'd want it to be a theorem (in Lean, Coq, Isabelle/HOL or whatever) instead of a constraint problem. So it would be more limited by developer effort than by computational power. Theoretically you can do this from software down to (idealized) gates, but in practice the effort is so great that it's only been done in extremely limited systems.
- tsimionescu 3y ago
  Formal methods are widely used in processor design. It is hard to formalize specs to assert behaviors that bugs we haven't thought about don't exist. At least hard while also preserving the property of being a Turing machine.
akoboldfrying 3y ago
Well, the bug in this specific case (based on the article by Tavis O. linked elsewhere in comments) looks to be the regular kind -- probably an off-by-one in a microcode edge case. That is, here it's not the case that the CPU functions correctly but leaves behind traces of things that should be private in timing side channels, as was the case for Spectre.
- trebligdivad 3y ago
  Yeh just a fun bug rather than anything too fundamental. Still, it is a fun bug.
JohnBooty 3y ago
Is the future leads to a swarm of disconnected A55 cores each running a single application? don't you dare tease me like that
- bobim 3y ago
  And programmed in… Forth!
lmm 3y ago
> Is it even possible to design a cpu with out-of-order and speculative execution that would have no security issue? Yes, of course. But we'd have to put actual effort in, and realistically people wouldn't pay enough extra to make it worthwhile.

by bobim 3y ago

SmoothBrain12 3y ago

Yes, but they won't clock as fast because they'll be waiting for RAM.

bobim 3y ago
We need to keep programs small so they fit in the cache.
- moffkalast 3y ago
  We need 2 GBs of L1 cache, thus solving the cache miss problem once and for all.
  - rep_lodsb 3y ago
    640K should be enough for anyone ;)

Tuna-Fish 3y ago

This vulnerability was not caused by OoO or speculative execution. It was caused by the fact that x86 was designed 45 years ago, and has had feature after feature piled on the same base, which has never been adequately rebuilt. The more proximate cause is that some instructions with multiple redundant prefixes (which is legal, but pointless) have their length miscalculated by some Intel CPUs, which results in wrong outcomes.

epcoa 3y ago
Not entirely pointless, redundant prefixes are occasionally the useful method for alignment.
- TheCoreh 3y ago
  A more sensible approach for that use-case would be IMO to have well-defined specialized prefixes for padding, instead of relying on the case-by-case behavior of redundant prefixes. (However I understand that there's almost certainly a good historical reason why this was not the way it was done)
  - bobim 3y ago
    Are new ISA solving this? Time to move to Risc V?
    - epcoa 3y ago
      N/A and No.
    - dontlaugh 3y ago
      RISC V is not great at this either, with the compression extension being common and variable length. ARM 64 gets this right, with fixed length 32 bit instructions.
      - snvzz 3y ago
        >ARM 64 gets this right, with fixed length 32 bit instructions. At the expense of code density, yet RISC-V is easy to decode, with implementations going up to 12-way decode (Veyron V2) despite variable length. ARM64 hardly "gets it right".
        camel-cdr 3y ago
        I wouldn't say ARM64 gets it wrong either, I think both are viable approaches.
gumby 3y ago
> It was caused by the fact that x86 was designed 45 years ago, and has had feature after feature piled on the same base, which has never been adequately rebuilt. Itanic would like to object! Unfortunately it can’t get through the door.

nextaccountic 3y ago

I think formal methods could help designing of such machine, if you can write a mathematical statement that amounts to "there is no side channel between A and B" Or at least put a practical bound on how many bits per second at most you can from any such side channel (the reasoning being, if you can get at most a bit for each million years, you probably don't have an attack) Then you verify if a given design meets this constraint

mgaunard 3y ago
A program is itself a formal specification of what an algorithm does.
- kiitos 3y ago
  Programs are implementations of specifications, they're not specifications themselves. Unless you're talking about like Coq or TLA+.
bobim 3y ago
What would be the typical size of such a constraint-based problem, and do we have the compute power to translate the rules into an implementation? And what if one forgot a rule somewhere… Deeply interesting subject.
- less_less 3y ago
  I think you'd want it to be a theorem (in Lean, Coq, Isabelle/HOL or whatever) instead of a constraint problem. So it would be more limited by developer effort than by computational power. Theoretically you can do this from software down to (idealized) gates, but in practice the effort is so great that it's only been done in extremely limited systems.
tsimionescu 3y ago
Formal methods are widely used in processor design. It is hard to formalize specs to assert behaviors that bugs we haven't thought about don't exist. At least hard while also preserving the property of being a Turing machine.

akoboldfrying 3y ago

Well, the bug in this specific case (based on the article by Tavis O. linked elsewhere in comments) looks to be the regular kind -- probably an off-by-one in a microcode edge case. That is, here it's not the case that the CPU functions correctly but leaves behind traces of things that should be private in timing side channels, as was the case for Spectre.

trebligdivad 3y ago
Yeh just a fun bug rather than anything too fundamental. Still, it is a fun bug.

JohnBooty 3y ago

Is the future leads to a swarm of disconnected A55 cores each running a single application? don't you dare tease me like that

bobim 3y ago
And programmed in… Forth!

lmm 3y ago

> Is it even possible to design a cpu with out-of-order and speculative execution that would have no security issue? Yes, of course. But we'd have to put actual effort in, and realistically people wouldn't pay enough extra to make it worthwhile.