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

[Jakub Jelinek]

On Thu, Sep 29, 2016 at 10:47:28AM +0100, Yuri Gribov wrote:
> > Do the sanitizers depend on direct calls to the interceptors from
> > application code, or can we add an indirection which has been compiled
> > *without* sanitizer support?
> 
> Cc Jakub.
> 
> No, there is not dependency on direct calls so indirection should work fine.
> 
> > If the indirection is acceptable, we could perhaps provided a DSO
> > which maps back the fortify wrappers to the unfortified versions.
> > libasan could link against that, for valgrind, it could be preloaded.
> 
> Disabling Glibc fortification through indirection should generally
> work (Kostya, Jakub -please comment if it's not). Actually it would be
> even better than asking users to disable Fortify when building with
> Asan because the tool will then be able to intercept calls to
> fortified functions from unsanitized parts of the program (and detect
> errors in such calls).
> 
> I'm just wondering if there are less invasive solutions e.g. providing
> a runtime Glibc setting (e.g. through environment variable) to disable
> fortification at startup? This shouldn't introduce significant
> performance penalty.

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?

> 
> > memstop could use this as well:
> >
> >   <https://bugzilla.redhat.com/show_bug.cgi?id=1034894>
> >
> > The advantage of the unfortify library is that it keeps the knowledge
> > about fortify wrappers in glibc.
> 
> Yes, duplicating this information in all existing instrumentation
> tools would be inefficient and error-prone.

Why?  There are not many of the __*_chk entrypoints, and it is fairly easy
to handle them.  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.).

	Jakub