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.
I’ve just uploaded a sequence of patches that implement a similar technique for
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
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
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:
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.