[llvm-commits] [PATCH] -fstack-protector-strong parts 1 and 2

[Magee, Josh]

Hi Bill, thank for you reviewing.

I made the alphabetization changes for patch 1.

I also updated part 2.  I discovered that it was possible for the analysis of
PHI nodes to get stuck in infinite recursion.  This could happen in loops where
a subsequent use of the PHI node was also an incoming value to the node.  The
fix for this is to keep track of the PHI nodes as they are analyzed and skip those
that have already been seen.

Additionally, I changed a few places where I was redundantly iterating through
all the operands of a use.  For example, in the case of the CallInst, I already
know that the CallInst is a use of AI so it isn't necessary to iterate over
every operand just to check for AI.  In this case the previous code wasn't
incorrect, but it was inefficient/unnecessary.

I don't have commit access, so I'd be very happy if you could apply for me
(assuming the updated patches are okay, of course.)

Thanks,
- Josh



________________________________________
From: Bill Wendling [wendling at apple.com]
Sent: 18 January 2013 16:51
To: Magee, Josh
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [PATCH] -fstack-protector-strong parts 1 and 2

Hi Josh,

Part II also looks fine to me. Go ahead and apply if you want. :)

-bw

On Jan 14, 2013, at 7:36 PM, "Magee, Josh" <Joshua.Magee at am.sony.com> wrote:

> Ping - with updated patches.
>
> Part 1 is an updated version of my previously attached patch, which adds the IR attribute  'sspstrong'.
> I could see that this patch by itself may not be that interesting or helpful in seeing where this feature is going, so attached the second patch as well.  Part 2 implements the strong heuristic itself.
> The requirements of the strong heuristic are:
> * A Protector is required for functions which contain an array, regardless of type or length.
> * A Protector is required for functions which contain a structure/union which
>  contains an array, regardless of type or length.  Note, there is no limit to the depth of nesting.
> * A protector is required when the address of a local variable (i.e., stack based variable) is exposed.  (E.g., such as through a local whose address is taken as part of the RHS of an assignment or a local whose address is taken as part of a function argument.)
>
> One of the requirements for standard SSP mode (-fstack-protector) was not fully met, so it needed to be tweaked.
> The requirements for the standard heuristic are:
> * Protector is required for a functions which contain a call to alloca with a variable size or constant size greater than ssp-buffer-size (default 8).
> The existing implementation would enable protectors for all calls to alloca.
>
> Please ask questions / make comments.
>
> The remaining patches are:
> Part 3 - Data layout Rules (Implements stricter data layout rules to place SSP-triggering variables closer to the protector)
> Part 4 - Clang Command line options
> Part 5 - Clang Attributes
>
> In the spirit of delivering in small increments, I would prefer to get the current patches reviewed before sending additional ones. :-)
>
>
> Thanks,
> Josh
>
>
> ________________________________________
> From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu] on behalf of Magee, Josh [Joshua.Magee at am.sony.com]
> Sent: 21 November 2012 17:50
> To: llvm-commits at cs.uiuc.edu
> Subject: [llvm-commits] [PATCH] -fstack-protector-strong part 1: sspstrong      IR attribute
>
> Hi,
>
> This is the first patch for an implementation of ssp-strong previously
> proposed to llvm-dev:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/053931.html
>
> This patch adds the IR attribute 'sspstrong'.  For now, sspstrong is treated
> identically to sspreq.  The actual "strong" heuristic will be provided in a
> subsequent patch.
>
> Rather than updating the documentation at the end, I plan to keep it in sync
> with each patch.  For now it lists 'sspstrong' as being equivalent to 'sspreq',
> but once the heuristic is in place then the docs will be updated accordingly.
> (If preferred the documentation could be provided at the end, but I thought
> delivering it incrementally along with the code would be better.)
>
> Thanks,
> Josh
> <part1-sspstrong-ir-attribute.diff><part2-sspstrong-heuristic.diff>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


-------------- next part --------------
A non-text attachment was scrubbed...
Name: part1-sspstrong-ir-attribute-0122.diff
Type: application/octet-stream
Size: 39086 bytes
Desc: part1-sspstrong-ir-attribute-0122.diff
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130123/1f8e71c2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part2-sspstrong-heuristic-0122.diff
Type: application/octet-stream
Size: 86433 bytes
Desc: part2-sspstrong-heuristic-0122.diff
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130123/1f8e71c2/attachment-0001.obj>