From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-73738-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 113108 invoked by alias); 5 Oct 2016 16:46:42 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 113094 invoked by uid 89); 5 Oct 2016 16:46:42 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mailbackend.panix.com
X-Gm-Message-State: AA6/9Rn6iZCH1ZZRkQ3tGGp+vV4azh4qB/Vga/ihkKVRYdbj/eAct6NNIsfOg9QJD1IG2DxJtZlSB5b/nyvqgQ==
X-Received: by 10.28.138.140 with SMTP id m134mr9400327wmd.92.1475685987962;
 Wed, 05 Oct 2016 09:46:27 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <CAN=P9pj5du+hE2xpGBUG99KLtzTYghd3YFpSaQL9VhE+x5fvww@mail.gmail.com>
References: <57CDAB08.8060601@samsung.com> <CAKCAbMgt7DWUmJFOOwWDoeXrh4WrZRDcfFxaapTcEJWXw_=59g@mail.gmail.com>
 <CAN=P9pj5du+hE2xpGBUG99KLtzTYghd3YFpSaQL9VhE+x5fvww@mail.gmail.com>
From: Zack Weinberg <zackw@panix.com>
Date: Wed, 05 Oct 2016 16:46:00 -0000
X-Gmail-Original-Message-ID: <CAKCAbMhXmCOOJp=eoxUzEmY=ik3oKsN9QrXYrsX61ocDZ2gnhw@mail.gmail.com>
Message-ID: <CAKCAbMhXmCOOJp=eoxUzEmY=ik3oKsN9QrXYrsX61ocDZ2gnhw@mail.gmail.com>
Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the
 same time.
To: Kostya Serebryany <kcc@google.com>
Cc: Maxim Ostapenko <m.ostapenko@samsung.com>, GNU C Library <libc-alpha@sourceware.org>, 
	Florian Weimer <fweimer@redhat.com>, Yuri Gribov <tetra2005@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2016-10/txt/msg00098.txt.bz2

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