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

[Yuri Gribov <tetra2005 at gmail dot com>]

On Thu, Sep 29, 2016 at 9:08 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Yuri Gribov:
>
>> Would the above approach be accepted for trunk? The reason for me
>> pushing this is because FORTIFY_SOURCE is now enabled by default in
>> major distros and this start to be a detrimental factor for ASan
>> efficiency (there are already 3 open bugs related to this in tracker
>> and they keep coming).
>
> We have received a related feature request:
>
>   <https://sourceware.org/bugzilla/show_bug.cgi?id=20644>
>
> 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.

> 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.

-Y