Comment by hlieberman | Hacker News Reader

Comment by hlieberman | Hacker News Reader

Parent Full thread

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...

What you say is true, but it's not the end of the story. Higher performance RISC-V CPU cores that do speculation are under development or in some cases have been announced but not yet shipped. They have the opportunity to design to avoid those vulnerabilities from the start, which is a lot easier than fixing things up afterwards -- or simply losing a lot of performance on already-shipped CPUs by turning features off.

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 :-)

> - 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 sounds interesting. How do these countermeasures actually prevent Spectre V1? And if they do, why didn't Intel implement them? Seems like they are fully microarchitectural, and therefore opaque to the software world.

All Spectre/Meltdown attacks go through the same 3 steps in this order:

1) taking control over transient instruction execution

2) controlled transient instructions access a legal data (but illegal for us)

3) controlled transient instructions exfiltrate this data through a side channel between the microarch and the arch

For Spectre V1: Step 1) is performed by the Branch-Predictor, step 2) depends on the gadget targeted within the victim code, and step 3) is completed using a FLUSH+RELOAD or a EVICT+RELOAD triggered by a transient load.

If one of these 3 steps is not met then the attack is impossible. The brucehoult proposal (obviously not the first to suggest this) is to eliminate step 3): if no transient execution side effect/microarchitectural state is made observable, then there is no way to exfiltrate data. All Spectre/Meltdown attacks are therefore made unfeasible.

The problem is that brucehoult's proposal does not guarantee that all side-channels are infeasible at all, it only guarantees that side channels based on branch prediction or caching are no longer possible.

Furthermore, microarchitectural optimizations are made to have an observable effect on the execution time. Therefore, it's likely that other timing side-channels will be exposed/discovered/used.

Yes, it is a fundamentally misleading assertion.

I made that statement in the article because that is what my research showed.

Reply on news.ycombinator.com