Re: Spectre V1 diagnostic / mitigation

[Jeff Law <law at redhat dot com>]

On 12/18/18 8:36 AM, Richard Biener wrote:
> 
> Hi,
> 
> in the past weeks I've been looking into prototyping both spectre V1 
> (speculative array bound bypass) diagnostics and mitigation in an
> architecture independent manner to assess feasability and some kind
> of upper bound on the performance impact one can expect.
> https://lists.llvm.org/pipermail/llvm-dev/2018-March/122085.html is
> an interesting read in this context as well.
> 
> For simplicity I have implemented mitigation on GIMPLE right before
> RTL expansion and have chosen TLS to do mitigation across function
> boundaries.  Diagnostics sit in the same place but both are not in
> any way dependent on each other.
> 
> The mitigation strategy chosen is that of tracking speculation
> state via a mask that can be used to zero parts of the addresses
> that leak the actual data.  That's similar to what aarch64 does
> with -mtrack-speculation (but oddly there's no mitigation there).
> 
> I've optimized things to the point that is reasonable when working
> target independent on GIMPLE but I've only looked at x86 assembly
> and performance.  I expect any "final" mitigation if we choose to
> implement and integrate such would be after RTL expansion since
> RTL expansion can end up introducing quite some control flow whose
> speculation state is not properly tracked by the prototype.
> 
> I'm cut&pasting single-runs of SPEC INT 2006/2017 here, the runs
> were done with -O2 [-fspectre-v1={2,3}] where =2 is function-local
> mitigation and =3 does mitigation global with passing the state
> via TLS memory.
> 
> The following was measured on a Haswell desktop CPU:
[ ... ]
Interesting.  So we'd been kicking this issue around a bit internally.

The number of packages where we'd want to turn this on was very small
and thus it was difficult to justify burning resources in this space.
LLVM might be an option for those limited packages, but LLVM is missing
other security things we don't want to lose (such as stack clash
mitigation).

In the end we punted for the immediate future.  We'll almost certainly
revisit at some point and your prototype would obviously factor into the
calculus around future decisions.

[ ... ]


> 
> 
> The patch relies heavily on RTL optimizations for DCE purposes.  At the
> same time we rely on RTL not statically computing the mask (RTL has no
> conditional constant propagation).  Full instrumentation of the classic
> Spectre V1 testcase
Right. But it does do constant propagation into arms of conditionals as
well as jump threading.  I'd fear they might compromise things.
Obviously we'd need to look further into those issues.  But even if they
do, something like what you've done may mitigate enough vulnerable
sequences that it's worth doing, even if there's some gaps due to "over"
optimization in the RTL space.

[  ... ]

> 
> so the generated GIMPLE was "tuned" for reasonable x86 assembler outcome.
> 
> Patch below for reference (and your own testing in case you are curious).
> I do not plan to pursue this further at this point.
Understood.  Thanks for posting it.  We're not currently working in this
space, but again, we may re-evaluate that stance in the future.

jeff