This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
- From: Zack Weinberg <zackw at panix dot com>
- To: Kostya Serebryany <kcc at google dot com>
- Cc: Maxim Ostapenko <m dot ostapenko at samsung dot com>, GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Wed, 5 Oct 2016 12:46:26 -0400
- Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
- Authentication-results: sourceware.org; auth=none
- References: <57CDAB08.8060601@samsung.com> <CAKCAbMgt7DWUmJFOOwWDoeXrh4WrZRDcfFxaapTcEJWXw_=59g@mail.gmail.com> <CAN=P9pj5du+hE2xpGBUG99KLtzTYghd3YFpSaQL9VhE+x5fvww@mail.gmail.com>
On Wed, Oct 5, 2016 at 12:10 PM, Kostya Serebryany <kcc@google.com> wrote:
> On Wed, Oct 5, 2016 at 9:06 AM, Zack Weinberg <zackw@panix.com> wrote:
>> On Mon, Sep 5, 2016 at 1:27 PM, Maxim Ostapenko <m.ostapenko@samsung.com> wrote:
>>> When fortify is used with MSan it will cause MSan false positives.
>> ... appears to me to be a plain old bug. Either the fortify shims are
>> actually using an uninitialized value, in which case they should be
>> fixed, or MSan has misunderstood the code generated in _FORTIFY_SOURCE
>> mode, in which case MSan should be fixed.
>>
>> You understand what is going on better than anyone else here, I think
>> - can you please write up a detailed description of exactly why this
>> goes wrong?
>
> * fortify replaces sprintf with sprintf_chk
> * msan does not know about sprintf_chk
> * sprintf_chk initializes 'text' but msan does not know that
OK, that's the bug right there, msan should know that.
Why is it hard to fix that bug? Why are we instead arguing over
whether we should prevent people from enabling both defensive measures
at the same time?
zw