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 11:04 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 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?

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.

Note that Florian's suggestion would not incur penalties in normal
(i.e. non-sanitized) case and sanitized executables will suffer one
additional indirect jump per call.

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

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.

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

-Y