3 ms·

Seems very unlikely that ISAs will have to change, the problem needs to be fixed in micro Architecture. Its unlikely that there are many mass production RISC-V

by nickik 9y ago

Seems very unlikely that ISAs will have to change, the problem needs to be fixed in micro Architecture. Its unlikely that there are many mass production RISC-V CPU currently in design. A couple are known but they are more advanced research projects. The BOOM core will be used by Esperanto and I'm sure they will evaluate what to do about the security issues. The guy who made BOOM written about this problems, check on Twitter.

_chris_ 9y ago
Spectre can be completely mitigated, it's just another headache to deal with. =( Essentially, you just have to buffer up more stuff and clear the misspeculated entries so nothing is left lying around that could leak information. Comes with a cost, but chip companies don't have to give up on OOO/speculation entirely.
- CodesInChaos 9y ago
  Sounds tricky. For example if your CPU has hyperthreading, cache misses in speculative execution could leak to the other thread running on the same core, because they share computational resources and the utilization of those is affected by cache misses in speculative execution.
  - _chris_ 9y ago
    You tag things and prevent bypassing uncommitted data from one thread to another. For example, it's a mistake (that's been made by other ISAs!) to allow two hardware threads to bypass store data out of the uncommitted StoreQueue from one thread to another. Your memory consistency model violates single-copy atomicity and now the programmer's life is much harder.
    - CodesInChaos 9y ago
      I'm talking about the shared computation resources (e.g. ALU), not about shared caches. Cache hits and cache misses affect how much and when one thread utilizes the ALU, which means the other thread sharing it won't be able to use the same resources for computation. Since speculative execution also uses these shared resources, it leaks information about its cache misses to the other thread, even if a rolled-back speculative execution doesn't modify any caches.

by nickik 9y ago

_chris_ 9y ago

Spectre can be completely mitigated, it's just another headache to deal with. =( Essentially, you just have to buffer up more stuff and clear the misspeculated entries so nothing is left lying around that could leak information. Comes with a cost, but chip companies don't have to give up on OOO/speculation entirely.

CodesInChaos 9y ago
Sounds tricky. For example if your CPU has hyperthreading, cache misses in speculative execution could leak to the other thread running on the same core, because they share computational resources and the utilization of those is affected by cache misses in speculative execution.
- _chris_ 9y ago
  You tag things and prevent bypassing uncommitted data from one thread to another. For example, it's a mistake (that's been made by other ISAs!) to allow two hardware threads to bypass store data out of the uncommitted StoreQueue from one thread to another. Your memory consistency model violates single-copy atomicity and now the programmer's life is much harder.
  - CodesInChaos 9y ago
    I'm talking about the shared computation resources (e.g. ALU), not about shared caches. Cache hits and cache misses affect how much and when one thread utilizes the ALU, which means the other thread sharing it won't be able to use the same resources for computation. Since speculative execution also uses these shared resources, it leaks information about its cache misses to the other thread, even if a rolled-back speculative execution doesn't modify any caches.