<div dir="ltr">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><br></div><div>There is no change to the proposed implementation which can already robustly mitigate these variants.</div><div><br></div><div>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><br></div>Notably:<div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 9, 2018 at 5:03 AM Kristof Beyls <<a href="mailto:Kristof.Beyls@arm.com">Kristof.Beyls@arm.com</a>> wrote:<br></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">
<div>Hi Chandler,</div>
<div><br>
</div>
<div>I've just uploaded a sequence of patches that implement a similar technique for</div>
<div>AArch64.</div></div></blockquote><div><br></div><div>This is awesome. =D I can't wait to start wiring this together.</div><div> </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">
<div>A small difference of approach is that I went for introducing an intrinsic that</div>
<div>can make any integer or pointer value "speculation-safe", i.e. the intrinsic</div>
<div>returns the value of its only parameter when correctly speculating, and returns</div>
<div>0 when miss-speculating.</div>
<div>The intrinsic is close to what Philip Reames suggested on</div>
<div><a href="https://reviews.llvm.org/D41761" target="_blank">https://reviews.llvm.org/D41761</a>.</div></div></blockquote><div><br></div><div>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> </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">
<div><br>
</div>
<div>Then a later patch (D49072) adds automatic mitigation by inserting the intrinsic</div>
<div>in necessary locations.</div></div></blockquote><div><br></div><div>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>I believe this approach has the advantage that:<br></div>
<div>a) it makes it possible to only insert a mitigation in specific locations if</div>
<div>   the programmer is capable of inserting intrinsics manually.</div></div></blockquote><div><br></div><div>This is definitely an area of great interest long-term.</div><div> </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">
<div>b) it becomes easier to explore different options for implementing automatic</div>
<div>   protection - it's just a matter of writing different ways on how the</div>
<div>   intrinsic is injected into the program. See D49072 for how this is relatively</div>
<div>   easy.</div></div></blockquote><div><br></div><div>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><br></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">
<div><br>
</div>
<div>I've split the patches according to the following functionality:</div>
<div>- LLVM: <a href="https://reviews.llvm.org/D49069:" target="_blank">https://reviews.llvm.org/D49069:</a> Introduce control flow speculation tracking for AArch64.</div>
<div>- LLVM: <a href="https://reviews.llvm.org/D49070:" target="_blank">https://reviews.llvm.org/D49070:</a> Introduce llvm.speculation_safe_value intrinsic.</div>
<div>- LLVM: <a href="https://reviews.llvm.org/D49071:" target="_blank">https://reviews.llvm.org/D49071:</a> Enable lowering of llvm.speculation_safe_value to DSB/ISB pair.</div>
<div>- LLVM: <a href="https://reviews.llvm.org/D49072:" target="_blank">https://reviews.llvm.org/D49072:</a> Enable automatic mitigation against control flow speculation.</div>
<div>- Clang: <a href="https://reviews.llvm.org/D49073:" target="_blank">https://reviews.llvm.org/D49073:</a> Introducing __builtin_speculation_safe_value.</div>
<div><br>
</div>
<div>I'll be on a long holiday soon, so there may be delays to me reacting on review feedback.</div></div></blockquote><div><br></div><div>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>