[LLVMdev] [PROPOSAL] Adding support for -fstack-protector-strong

[Magee, Josh]

At 1349295623 seconds past the Epoch, Robinson, Paul wrote:
> David Chisnall wrote:
> >On 2 Oct 2012, at 03:26, Magee, Josh wrote:
> >
> >>    1) An address of a local variable is taken in such a way as to expose the
> >>       address of a stack location.
> >>      - Example: the address of a local on the RHS of an assignment, the
> >>        address of a local passed into function.
> >
> > It also sounds like it would be triggered for a lot of C++ function s that
> > allocates an object on the stack and call methods on them.  Is it possible
> > to tighten up the heuristic slightly so that this isn't the case?  
> 
> I don't see any inherent difference (for this purpose) between
>     void foo() {
>       int x;
>       someFunc(&x);
>     }
> and
>     void foo() {
>       SomeClass x;
>       x.someNonStaticMethod();
>     }
> It's just that C++ is so good at obscuring the details.  Granted there is 
> no & operator in the second case, but the address of the stack-local object
> is available to the called method without any hijinks, just like the address
> of the stack-local variable is available to someFunc in the first case.

Right, in both cases a stack address is exposed.  Both usages are so
common place that this will end up triggering protectors for a lot of
functions.  In cases where the IR of the called function/method is
available, then it sounds reasonable to verify whether the callee
actually does anything "unsafe" with the address before triggering a
protector.

I'm not especially familiar with Blocks, but given that the IR is
always available then it makes sense to tighten up the heuristic
for Blocks first.  After that it could be improved/tweaked for methods.

I think once the initial strong heuristic is in place, then we can
improve/tweak it as desired to accommodate these issues.

- Josh