<div dir="ltr"><br>We went with this approach because we were trying to catch the most likely vulnerabilities while also trying to limit the number of false positives. As speculative execution of a branch is fundamental to the Spectre exploit, linking the loads to conditional branches was an obvious way to try and limit the number of possibilities. We've worked closely with our internal users to come up with something that meets their requirements, and as a side effect decided to share our implementation with the wider LLVM community.  Our solution seems to match fairly closely that which we've observed to mitigate Variant 1 in the Linux Kernel [1] and by other compiler vendors such as Microsoft [2].  It's true that there is a danger of introducing a false sense of security. But the fact you can't guarantee to find all the vulnerabilies doesn't mean you do nothing.  To echo Paul, you don't leave your house unlocked because you can't make it 100% burglar-proof!<br><br>[1] <a href="https://lwn.net/Articles/743265/">https://lwn.net/Articles/743265/</a><br><br>[2] <a href="https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/">https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2018 at 01:53, Eli Friedman via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">efriedma added a comment.<br>
<br>
I think the focus on array bounds checks is overly narrow.  You can get an almost identical effect in other ways. For example, if you use C++ inheritance, a member of an object might be a user-controlled integer on one path, and a pointer on a different path.  Or if you have an array of pointers, you could read past the end of the array into uninintialized data.<br>
<br>
You could write an analysis which is more comprehensive by analyzing every load, I think, rather than trying to figure out which loads are related to branches. A pointer to some known object is "safe", a constant offset from a "safe" pointer is also "safe", a SCEV AddRec whose base is a "safe" pointer is also "safe", etc., and then warn about any pointers the analysis can't prove safe.  The tricky part of this would be handling pointers to pointers; not sure what sort of heuristic you would use.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D43643" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D43643</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>