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: Jakub Jelinek <jakub at redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Kostya Serebryany <kcc at google dot com>, Andrew Pinski <pinskia at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>, Maxim Ostapenko <m dot ostapenko at samsung dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 2 Oct 2016 11:39:53 +0200
- Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
- Authentication-results: sourceware.org; auth=none
- References: <8d2403c8-466d-8f1a-e563-8b729deef9ce@redhat.com> <CAJOtW+5r0NQOHh1MKGSoCVyDto7LtJE7d3-oqJy-Yei6AECb8g@mail.gmail.com> <87lgyb9lhf.fsf@mid.deneb.enyo.de> <CAJOtW+7xjtx=DxEOSnaPfpU708RdUJYLRX8prv0bFW=x47+tmA@mail.gmail.com> <20160929100429.GQ7282@tucnak.redhat.com> <CAJOtW+5gnekVLcnUCrHWjYL1agspyZ-v_kOgEp8kyCrviGADJw@mail.gmail.com> <20160929104408.GR7282@tucnak.redhat.com> <CA+=Sn1mj83AL=XKinTbJDwOEEVReVFWTsbprKuVVMbsu=OdA7w@mail.gmail.com> <CAN=P9pjzpygMJKjUDtkKxRn4+4BDG_wJ3qbQhehSJa5UenV6gA@mail.gmail.com> <87fuofp4sq.fsf@mid.deneb.enyo.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sun, Oct 02, 2016 at 09:51:17AM +0200, Florian Weimer wrote:
> * Kostya Serebryany:
>
> > 80 interceptors to support *san and fortification is 80 too many, IMHO.
> > The fact that other pre-compiled libraries use fortify by default is very sad.
> > I think this is a clear case of misuse of fortify because now users of
> > the library can't opt out.
>
> If we had some libc-unfortify.so DSO, you *could* opt out.
>
> > If someone is willing to provide a patch to sanitizers that is
> > * in sanitizer_common,
> > * uses a separate file for all of these 80 functions,
> > * does not touch any other file (in a significant way, at least)
> > * has tests
> > I'll most likely accept it.
>
> Why do you want to put this into sanitizer_common?
>
> It would make more sense to maintain this inside glibc, so that it can
> be updated in sync with fortification development. We can keep an eye
> on the ability to build the sources separately from glibc, to bridge
> the time until this DSO is routinely shipped as part of glibc.
Because you really don't know what kind of information will each tool want
to know, and that can significantly differ between valgrind, [amt]san etc.
In sanitizer_common, you can come up with some macros that will serve the
needs of all the tools, and have each tool use those macros, other than
that, it is a trivial 3 liner wrapper for each fortification function.
Jakub