<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 11 Jul 2018, at 13:02, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">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).
<div class=""><br class="">
</div>
<div class="">There is no change to the proposed implementation which can already robustly mitigate these variants.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
Notably:
<div class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Mon, Jul 9, 2018 at 5:03 AM Kristof Beyls <<a href="mailto:Kristof.Beyls@arm.com" class="">Kristof.Beyls@arm.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">Hi Chandler,</div>
<div class=""><br class="">
</div>
<div class="">I've just uploaded a sequence of patches that implement a similar technique for</div>
<div class="">AArch64.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">This is awesome. =D I can't wait to start wiring this together.</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">A small difference of approach is that I went for introducing an intrinsic that</div>
<div class="">can make any integer or pointer value "speculation-safe", i.e. the intrinsic</div>
<div class="">returns the value of its only parameter when correctly speculating, and returns</div>
<div class="">0 when miss-speculating.</div>
<div class="">The intrinsic is close to what Philip Reames suggested on</div>
<div class=""><a href="https://reviews.llvm.org/D41761" target="_blank" class="">https://reviews.llvm.org/D41761</a>.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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...</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><br class="">
</div>
<div class="">Then a later patch (D49072) adds automatic mitigation by inserting the intrinsic</div>
<div class="">in necessary locations.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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….</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>My guess is that the key is that the automatic intrinsic insertion happens only really really late in my implementation - i.e. in the same pass that also inserts the speculation tracking.</div>
<div>One could say that there really isn’t that much difference between inserting an intrinsic this way and just inserting instructions directly, since the intrinsic that gets inserted gets lowered almost immediately by the same pass later on.</div>
<div>It still has the advantage that the automatic protection code remains simple and the actual lowering from intrinsic to instruction sequences is shared between the automatic mode and the user-inserted intrinsic mode.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="gmail_quote">
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">I believe this approach has the advantage that:<br class="">
</div>
<div class="">a) it makes it possible to only insert a mitigation in specific locations if</div>
<div class=""> the programmer is capable of inserting intrinsics manually.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">This is definitely an area of great interest long-term.</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">b) it becomes easier to explore different options for implementing automatic</div>
<div class=""> protection - it's just a matter of writing different ways on how the</div>
<div class=""> intrinsic is injected into the program. See D49072 for how this is relatively</div>
<div class=""> easy.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><br class="">
</div>
<div class="">I've split the patches according to the following functionality:</div>
<div class="">- LLVM: <a href="https://reviews.llvm.org/D49069:" target="_blank" class="">
https://reviews.llvm.org/D49069:</a> Introduce control flow speculation tracking for AArch64.</div>
<div class="">- LLVM: <a href="https://reviews.llvm.org/D49070:" target="_blank" class="">
https://reviews.llvm.org/D49070:</a> Introduce llvm.speculation_safe_value intrinsic.</div>
<div class="">- LLVM: <a href="https://reviews.llvm.org/D49071:" target="_blank" class="">
https://reviews.llvm.org/D49071:</a> Enable lowering of llvm.speculation_safe_value to DSB/ISB pair.</div>
<div class="">- LLVM: <a href="https://reviews.llvm.org/D49072:" target="_blank" class="">
https://reviews.llvm.org/D49072:</a> Enable automatic mitigation against control flow speculation.</div>
<div class="">- Clang: <a href="https://reviews.llvm.org/D49073:" target="_blank" class="">
https://reviews.llvm.org/D49073:</a> Introducing __builtin_speculation_safe_value.</div>
<div class=""><br class="">
</div>
<div class="">I'll be on a long holiday soon, so there may be delays to me reacting on review feedback.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="">
</div>
<div>It sounds great that there are beta testers eager to experiment with this approach, so I agree that pressing on with committing something that they can experiment with is the right approach here. Their feedback can only make the end solution better.</div>
<div><br class="">
</div>
<div>Thanks!</div>
<div><br class="">
</div>
<div>Kristof</div>
<br class="">
</body>
</html>