|
|
|
|
|
|
by oldnews193
1729 days ago
|
|
|
> - 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. |
|
|
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.