This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/20422] do not allow asan/msan/tsan and fortify at the same time.

--- Comment #6 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
(In reply to Florian Weimer from comment #5)
> These days, _FORTIFY_SOURCE covers additional aspects (including enhanced
> compile-time type safety), not just buffer-length checking.  I'm not sure
> what the current expectations regarding the sanitizers are.  Is it the norm
> to compile twice, for production (with -D_FORTIFY_SOURCE=2), and for special
> testing with the required sanitizer?
> I'm asking this because if there is just a single compile (say with Address
> Sanitizer), then I think we need to make the enhanced type safety (and other
> goodies) available to sanitizer users as well.

Typically, asan/msan/tsan are used as testing tools, not for production build.
And anyway, there are 3 of them, so you can't have a single build anyway. 
asan is sometimes used for production (e.g. on a small subset of servers)
to find the last remaining bugs. 
Very rarely asan is used as a hardened production build,
but the security value of this is disputable (at least, with the current

Can you give examples (or point to docs) of the "additional aspects" of
If they fit well into asan's architecture we will certainly want to either
have them duplicated in asan or make asan work with those parts of fortify. 

The traditional parts of fortify (where it replaces foo with foo_chk)
are *san-hostile at the moment.

You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]