[PATCH] D43643: [RFC] Sceptre a Spectre variant 1 detector

[Robert Lougher via llvm-commits]

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!

[1] https://lwn.net/Articles/743265/

[2]
https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/

On 23 February 2018 at 01:53, Eli Friedman via Phabricator <
reviews at reviews.llvm.org> wrote:

> efriedma added a comment.
>
> 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.
>
> 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.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D43643
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180223/56dd5fbc/attachment.html>