Message ID | 20200918164729.31994-1-will@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | Fix and rewrite arm64 spectre mitigations | expand |
On the off-chance that anybody's reading this... On Fri, Sep 18, 2020 at 05:47:10PM +0100, Will Deacon wrote: > The temptation was to remove the code entirely, but after putting in > some effort to untangle it, we ended up knocking it into a much better > shape. Although that doesn't change the fact that we can't test it very > well, it certainly appears to behave better than the old code in situations > such as: > > - Err... wanting mitigation on more than one CPU > > - Not changing the mitigation state at runtime (i.e. after userspace > has started running) > > - Gracefully handling failure to bring late CPUs online (previously > this would only happen _after_ updating the mitigation state!) > > - Clear separation between mitigation state (am I vulnerable?) and > policy (the user wants to go fast) > > - Removal of the hideously expensive "dynamic" Spectre-v2 mitigation > for KVM guests ^^^ This should be 'hideously expensive "dynamic" Spectre-v4 mitigation'. The firmware call itself is helpfully named "workaround 2", so I always get them mixed up. Will