From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14169 invoked by alias); 29 Sep 2016 10:44:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 14133 invoked by uid 89); 29 Sep 2016 10:44:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=2.12, libcso6, forwarding X-HELO: mx1.redhat.com Date: Thu, 29 Sep 2016 10:44:00 -0000 From: Jakub Jelinek To: Yuri Gribov Cc: Florian Weimer , Maxim Ostapenko , GNU C Library , Kostya Serebryany Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time. Message-ID: <20160929104408.GR7282@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <57CDAB08.8060601@samsung.com> <8d2403c8-466d-8f1a-e563-8b729deef9ce@redhat.com> <87lgyb9lhf.fsf@mid.deneb.enyo.de> <20160929100429.GQ7282@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-09/txt/msg00584.txt.bz2 On Thu, Sep 29, 2016 at 11:32:19AM +0100, Yuri Gribov wrote: > > 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. ASan/TSan/MSan can all share the same implementation, like they share various other wrappers. And the needs of the different tools are so different that adding a preload DSO that just ignores it will not help at all, usually you really don't want to ignore it, but complain using your tools diagnostic framework, for that you need to know what argument is objsz, against what it is compared (some other argument, strlen of some argument, something else) etc. > > 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. So what? In most cases with sufficient macros you'll need just one or three lines for each. Basically return type, function name, arguments and their types, how they map to the underlying non-fortified fn, what is the objsz argument and against what it is compared. BTW, I only count 80 on my box with glibc 2.21: nm -D /lib64/libc.so.6 | awk '/_chk/{print $3}' | sort -u | wc -l > > 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. It adds them very rarely, and never changes, it has to maintain the ABI. Jakub