On Fri, Oct 12, 2012 at 12:26 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Thu, Oct 11, 2012 at 10:05:54PM -0700, Xinliang David Li wrote:
>> Was:
>> Type global;
>> Now:
>> struct { // at least 32-byte aligned
>> Type orig;
>> char redzone[32 + required_for_alignment];
>> } global;
>>
>> All uses of global in the module should be replaced with global.orig
>>
>> (Note that the actual implementation does not need to change global
>> type nor references -- just adding the padding space)
>
> Yeah, IMHO it is easier to hook into varasm.c and just force the higher
> alignment and append padding after globals to be instrumented.
> The vars can be exported, we don't want to affect their .size, etc.
>
I think so too. Changing types and IR references will be too heavy
weight for it.
>> 4) Implement stack redzones:
>>
>> Collect all local variables that are still on stack (not on virtual
>> registers).
>> Create a new local variable of size enough to hold all current locals
>> and their redzones.
>> Replace uses of locals with the new variable (Note that this does not
>> need to happen in IR, only add guard space in stack layout)
>> Poison the stack at function entry (one or two stores per local variable).
>> Unpoison the stack at function exits (maybe including all cleanup landing
>> pads?)
>> Was:
>> int foo() {
>> Type1 a;
>> Type2 b;
>> <code that uses 'a' and 'b'; they are not on virtual registers>
>> return;
>> }
>> Now:
>> int foo() {
>> struct { // 32-byte aligned
>> char redzone0[32];
>> Type1 a;
>> char redzone1[32 + required_alignment_a];
>> Type2 b;
>> char redzone2[32 + required_alignment_b];
>> } locals;
>>
>> int *shadow_base = ((&locals.redzone0)>>3)+kAsanOffset;
>> shadow_base[0] = 0xffffffff; // poison redzone0
>> // poison the rest
>>
>> <code that uses 'locals.a' and 'locals.b'>
>>
>> shadow_base[0] = 0; // unpoison redzone0
>> // unpoison the rest
>> return;
>> }
>
> We don't need to do this at the GIMPLE level, instead we can hook into
> cfgexpand.c var layout code.
Yes.
> BTW, I wonder if for ASAN_SHADDOW_SHIFT 3
> we really need to force 32-byte alignment for the stack vars (as opposed
> to use the highest alignment among the protected vars). 32-byte alignment
> is fairly expensive, and if none of the vars actually need 32-byte
> alignment, I'd hope that 16-byte alignment should be enough. The redzones
> would still be 32-byte etc.
>
I wonder about the 32 byte alignment requirement too.
thanks,
David
By doing this during expand we can keep say -fstack-protector to do its job
> too.
> LLVM seems to emit 0xf1, 0xf2, 0xf3 etc. bytes into shadow memory for
> various parts of the padding (left, middle, right).
>
> Jakub
