| At least one of the points in this article isn't true. The article states "RISC-V is not affected by the Meltdown and Spectre vulnerabilities... [because it does] not perform any speculative memory accesses" -- but that's only true for some designs, not anything done by the ISA. Many of the higher performance RISC-V designs do, in fact, do speculation. RISC-V BOOM[0], by Berkeley, is vulnerable to Spectre[1][2]. One of the attempts to create an extension to the RISC-V ISA that has integrated security features (CHERI, [3]) itself was shown to be vulnerable to Spectre-like attacks[4]. The fact that most RISC-V chips were not vulnerable to Spectre is simply because they hadn't implemented a particular kind of performance optimization, not because there was anything intrinsic to the ISA that prevented them from being so. [0]: https://boom-core.org/ [1]: https://github.com/abejgonzalez/boom-attacks [2]: https://boom-core.org/docs/replicating_mitigating_spectre_ca... [3]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... [4]: https://kth.diva-portal.org/smash/get/diva2:1538245/FULLTEXT... |
It's not actually very hard to avoid these kids of vulnerabilities. All that is needed is to not permanently update state until the instruction is no longer speculative.
For example:
- don't update the branch prediction tables until the branch is proven to execute
- if loading a cache line causes another cache line to be evicted, keep both until it is known whether the load is supposed to execute
This requires provisioning a few more of these kinds of resources than you might previously have had, which costs a little silicon area, but it doesn't cost speed. Sometimes particularly demanding code might cause you to run out of these speculation resources and then you have to stall until an entry is freed up. This can already happen with things such as store buffers. If it never happens then you've probably over-provisioned :-)