This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
On Tue, Sep 6, 2016 at 10:13 AM, Florian Weimer <firstname.lastname@example.org> wrote:
> On 09/06/2016 10:58 AM, Yuri Gribov wrote:
>>> We could conceivably guard every _chk wrapper (say __sprintf_chk) with
>>> #ifndef __fortify_no___sprintf_chk
>>> . In sanitizer mode, for those wrappers you have deemed to be
>>> the compiler would define these macros, so that glibc wouldn't install
>> Or just undefine _FORTIFY_SOURCE?
> Well, but this way, you'll lose the completely unrelated alternative
> implementations which might still be useful because none of the sanitizers
> cover these aspects.
But isn't it the same with Valgrind - it doesn't play nice with
sanitizers (because both tools are far too complicated) but noone
really cares to fix this and just people just perform separate
>>> Another option would be to provide a glibc which has been compiled with
>>> required sanitizers, so that most interceptors become unnecessary.
>> Two important things to consider:
>> * sanitized Glibc will be slower (potentially much slower) than
>> current approach (because interceptors are heavily optimized)
> But in turn, you might uncover more bugs (mostly in glibc, but also in
> applications because the interceptors happen to be slightly off in the
> behavior they model).
Definitely. Sanitized Glibc would be great but it would be alternative
to interceptor-based approach, not a replacement.
>> * I'm unaware of any plans to implement sanitized Glibc (even though
>> prototype has been available for 1+ year)
> I hope to get remove the last remaining nested functions soon, if that's any