Re: [PATCH v2] Support ASan ODR indicators at compiler side.

[Maxim Ostapenko <m dot ostapenko at samsung dot com>]

On 21/11/16 15:17, Jakub Jelinek wrote:
> On Mon, Nov 21, 2016 at 12:09:30PM +0000, Yuri Gribov wrote:
> > On Mon, Nov 21, 2016 at 11:50 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > > On Mon, Nov 21, 2016 at 11:43:56AM +0000, Yuri Gribov wrote:
> > > > > This is just weird.  DECL_NAME in theory could be NULL, or can be a symbol
> > > > > much longer than 100 bytes, at which point you have strlen (tmp_name) == 99
> > > > > and ASM_GENERATE_INTERNAL_LABEL will just misbehave.
> > > > > I fail to see why you need tmp_name at all, I'd go just with
> > > > >    char sym_name[40];
> > > > >    ASM_GENERATE_INTERNAL_LABEL (sym_name, "LASANODR", ++lasan_odr_ind_cnt);
> > > > > or so.
> > > > Given that feature is quite new and hasn't been tested too much (it's
> > > > off by default in Clang), having a descriptive name may aid with
> > > > debugging bug reports.
> > > What would those symbols help with in debugging bug reports?
> > > You need to have a source reproducer anyway, then anybody can try it
> > > himself.
> > Well, in case of some weird symbol error at startup we can at least
> > understand which library/symbol to blame.
> >
> > > Even from just pure *.s file, you can look up where the
> > > .LASANODR1234 is used and from there find the corresponding symbol.
> > > Plus, as I said, with 95 chars or longer symbols (approx.) you get a buffer
> > > overflow.  We don't use descriptive symbols in other internal asan, dwarf2
> > > etc. labels.
> > Note that indicators need to have default visibility so simple scheme
> > like this will cause runtime collisions.
> But then why do you use ASM_GENERATE_INTERNAL_LABEL?  That is for internal
> labels.  If the indicators are visible outside of TUs, then their mangling
> is an ABI thing.  In that case you shouldn't add any kind of counter
> to them, but you should use something like __asan_odr.<name> or something
> similar, and if . is not supported in symbol names, use $ instead and if
> neither, then just disable the odr indicators.
>
> Or how exactly are these odr indicators supposed to work?

Odr indicators act as visible "delegates" of protected by ASan globals 
(their private aliases actually). We introduce them to catch cross-dso 
symbols clashing at runtime.
Of course, some people intentionally use ELF interposition and ASan 
would generate false alarm there, but a) we can use suppressions to 
avoid false alarms here and b) I believe in most cases such an alarm 
would indicate a real bug in user's code.

-Maxim

> 	Jakub