[asan] WIP protection of globals

[Xinliang David Li]

On Tue, Oct 16, 2012 at 4:02 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Oct 16, 2012 at 03:50:27PM -0700, Xinliang David Li wrote:
>> Does that mean that all globals defined in shared libraries can not be
>> protected as long as they are not protected or hidden? This sounds
>> like a big limitation.  We need to answer the following two questions:
>
> For !DECL_ONE_ONLY !DECL_COMMON vars you can protect them just fine,
> just do:
>         .globl  i
>         .data
>         .align 32
>         .type   i, @object
>         .size   i, 4
> i:
>         .long   7
>         .skip   60
>         .set    .LASAN.i,i
> and refer to .LASAN.i (i.e. a local alias) instead of i (or, as I said
> earlier, with ABI change of __asan_*register_globals or some alternative
> entrypoint for that it can be .LASAN.i-. and thus a PC-relative, not
> dynamic, relocation).  If i is preempted by a different i in another
> library, each shared library simply protects the red zone after its own var,
> and the fact that only one i is actually used by the program doesn't matter
> much.
>

Ok, using local aliases for those cases sound good.

>> 1) How often are exported variables get preempted?
>
> It is not uncommon, and DECL_ONE_ONLY is preempted very often.
>
>> 2) Is it a common use case to mix -fasan and -fno-asan ?
>
> -fasan shouldn't be an ABI option IMHO, and changing the size of globals is
> ABI changing.
>

I am not sure -- fasan is an error detecting feature -- the goal is to
find bugs -- missing handling of commons etc. are not desirable.
Besides  if ABI changes consistently for all objects, why does it
matter?

Or making common/decl_one_only protected under an additional option.

thanks,

David


>> > And for DECL_COMMON, you can't put any padding after a common variable
>> > without making the size of the common var larger (and increasing its
>> > alignment), both are undesirable for -fasan/-fno-asan mixing.
>>
>> If the linker picks the large one (which I believe it does), is that
>> still a problem?
>
> Yes.  For copy relocations at least.
>
>         Jakub