Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Sep 29, 2016 at 11:32:19AM +0100, Yuri Gribov wrote:
> > Ugh, so you want to slow down the performance critical common path of some
> > of the most often used functions just to avoid adding small code to the
> > sanitizers and valgrind?
> 
> Well, I think it's not just ASan and valgrind but rather all (or most
> of) dynamic instrumentation tools (TSan, MSan, dmalloc, etc.). We
> suggest to handle forwarding in one place rather than ask all tools
> developers to re-implement it.

ASan/TSan/MSan can all share the same implementation, like they share
various other wrappers.  And the needs of the different tools are so
different that adding a preload DSO that just ignores it will not help at
all, usually you really don't want to ignore it, but complain using your
tools diagnostic framework, for that you need to know what argument is
objsz, against what it is compared (some other argument, strlen of some
argument, something else) etc.

> > Why?  There are not many of the __*_chk entrypoints, and it is fairly easy
> > to handle them.
> 
> I can only access 2.12 now (yeah...) but it has 90+ *_chk APIs. Surely
> not all are necessary but that's still a lot of new interceptors.

So what?  In most cases with sufficient macros you'll need just one or three
lines for each.  Basically return type, function name, arguments and their
types, how they map to the underlying non-fortified fn, what is the objsz
argument and against what it is compared.
BTW, I only count 80 on my box with glibc 2.21:
nm -D /lib64/libc.so.6 | awk '/_chk/{print $3}' | sort -u | wc -l

> > E.g. asan has hundreds to thousands of wrappers, and most
> > of the *_chk entrypoints could be easily macrofied and the tool (asan,
> > valgrind) can then decide what it prefers to do with them (ignore the __bos
> > supplied argument, or add another diagnostics for the UB, etc.).
> 
> It's not just about implementing them but also synchronizing when
> Glibc adds new fortified implementations or changes their interfaces.

It adds them very rarely, and never changes, it has to maintain the ABI.

	Jakub