[llvm-dev] RFC: Speculative Load Hardening (a Spectre variant #1 mitigation)

[Chandler Carruth via llvm-dev]

FYI to all: I've updated the design document to include the newly disclosed
variants 1.1 and 1.2 (collectively called Bounds Check Bypass Store or
BCBS).

There is no change to the proposed implementation which can already
robustly mitigate these variants.

I've also updated my patch as we have very significant interest in getting
at least an early "beta" version of this into the tree and available for
experiments right away. Would really appreciate folks making review
comments ASAP and bearing with us and tolerating some amount of post-commit
iteration here.

Notably:

On Mon, Jul 9, 2018 at 5:03 AM Kristof Beyls <Kristof.Beyls at arm.com> wrote:

> Hi Chandler,
>
> I've just uploaded a sequence of patches that implement a similar
> technique for
> AArch64.
>

This is awesome. =D I can't wait to start wiring this together.


> A small difference of approach is that I went for introducing an intrinsic
> that
> can make any integer or pointer value "speculation-safe", i.e. the
> intrinsic
> returns the value of its only parameter when correctly speculating, and
> returns
> 0 when miss-speculating.
> The intrinsic is close to what Philip Reames suggested on
> https://reviews.llvm.org/D41761.
>

Cool, we'll definitely need *some* intrinsic in the IR to help model source
annotations. I still need to think a bit about the interface and model for
this...


>
> Then a later patch (D49072) adds automatic mitigation by inserting the
> intrinsic
> in necessary locations.
>

I was never able to get automatic mitigation with an intrinsic to avoid
really signiifcant performance problems in the x86 backend. I'll look
through your approach to see if you figured out a technique that works
better than the ones I tried here....


> I believe this approach has the advantage that:
> a) it makes it possible to only insert a mitigation in specific locations
> if
>    the programmer is capable of inserting intrinsics manually.
>

This is definitely an area of great interest long-term.


> b) it becomes easier to explore different options for implementing
> automatic
>    protection - it's just a matter of writing different ways on how the
>    intrinsic is injected into the program. See D49072 for how this is
> relatively
>    easy.
>

As above, I actually tried this and it backfired in terms of code quality.
I'll definitely look at this and either try to explain the problem I hit or
if you've dodged nicely, we can rework things to move in this direction.


> I've split the patches according to the following functionality:
> - LLVM: https://reviews.llvm.org/D49069: Introduce control flow
> speculation tracking for AArch64.
> - LLVM: https://reviews.llvm.org/D49070: Introduce
> llvm.speculation_safe_value intrinsic.
> - LLVM: https://reviews.llvm.org/D49071: Enable lowering of
> llvm.speculation_safe_value to DSB/ISB pair.
> - LLVM: https://reviews.llvm.org/D49072: Enable automatic mitigation
> against control flow speculation.
> - Clang: https://reviews.llvm.org/D49073: Introducing
> __builtin_speculation_safe_value.
>
> I'll be on a long holiday soon, so there may be delays to me reacting on
> review feedback.
>

Sure. Given the sudden but very strong interest we have from some users,
I'm going to try and make progress landing at least the initial version of
the x86 stuff. But I very much want to iterate on it and get it and the
AArch64 stuff you've got here to line up and work together. I really like
the overall direction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180711/6b9e8913/attachment.html>