public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Yuri Gribov <tetra2005@gmail.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
	Maxim Ostapenko <m.ostapenko@samsung.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	Kostya Serebryany <kcc@google.com>
Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
Date: Thu, 29 Sep 2016 10:04:00 -0000	[thread overview]
Message-ID: <20160929100429.GQ7282@tucnak.redhat.com> (raw)
In-Reply-To: <CAJOtW+7xjtx=DxEOSnaPfpU708RdUJYLRX8prv0bFW=x47+tmA@mail.gmail.com>

On Thu, Sep 29, 2016 at 10:47:28AM +0100, Yuri Gribov wrote:
> > Do the sanitizers depend on direct calls to the interceptors from
> > application code, or can we add an indirection which has been compiled
> > *without* sanitizer support?
> 
> Cc Jakub.
> 
> No, there is not dependency on direct calls so indirection should work fine.
> 
> > If the indirection is acceptable, we could perhaps provided a DSO
> > which maps back the fortify wrappers to the unfortified versions.
> > libasan could link against that, for valgrind, it could be preloaded.
> 
> Disabling Glibc fortification through indirection should generally
> work (Kostya, Jakub -please comment if it's not). Actually it would be
> even better than asking users to disable Fortify when building with
> Asan because the tool will then be able to intercept calls to
> fortified functions from unsanitized parts of the program (and detect
> errors in such calls).
> 
> I'm just wondering if there are less invasive solutions e.g. providing
> a runtime Glibc setting (e.g. through environment variable) to disable
> fortification at startup? This shouldn't introduce significant
> performance penalty.

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?

> 
> > memstop could use this as well:
> >
> >   <https://bugzilla.redhat.com/show_bug.cgi?id=1034894>
> >
> > The advantage of the unfortify library is that it keeps the knowledge
> > about fortify wrappers in glibc.
> 
> Yes, duplicating this information in all existing instrumentation
> tools would be inefficient and error-prone.

Why?  There are not many of the __*_chk entrypoints, and it is fairly easy
to handle them.  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.).

	Jakub

  reply	other threads:[~2016-09-29 10:04 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-05 17:27 Maxim Ostapenko
2016-09-05 19:48 ` Andrew Pinski
2016-09-06  8:39 ` Florian Weimer
2016-09-06  8:58   ` Yuri Gribov
2016-09-06  9:13     ` Florian Weimer
2016-09-06  9:20       ` Yuri Gribov
2016-09-06  9:51         ` Florian Weimer
2016-09-09 22:35       ` Kostya Serebryany
     [not found]       ` <CAN=P9phe_OP+tU+nnDDPEeZCR77w2ddrSX+LtSnx2-42p9JgUg@mail.gmail.com>
2016-09-12  9:36         ` Florian Weimer
2016-09-06  9:16   ` Maxim Ostapenko
2016-09-06  9:44     ` Florian Weimer
2016-09-09 22:36     ` Kostya Serebryany
2016-09-12  9:31       ` Florian Weimer
2016-09-12 18:54         ` Kostya Serebryany
2016-09-17  9:00   ` Yuri Gribov
2016-09-29  8:08     ` Florian Weimer
2016-09-29  9:47       ` Yuri Gribov
2016-09-29 10:04         ` Jakub Jelinek [this message]
2016-09-29 10:32           ` Yuri Gribov
2016-09-29 10:44             ` Jakub Jelinek
2016-09-29 10:52               ` Andrew Pinski
2016-09-29 21:23                 ` Kostya Serebryany
2016-10-01 21:38                   ` Andrew Pinski
2016-10-01 21:50                     ` Jakub Jelinek
2016-10-02  7:51                   ` Florian Weimer
2016-10-02  9:40                     ` Jakub Jelinek
2016-10-02  9:43                       ` Florian Weimer
2016-10-02 14:02                         ` Yuri Gribov
2016-10-04  0:53                           ` Kostya Serebryany
2016-10-04  6:46                             ` Jakub Jelinek
2016-10-04 12:15                               ` fortification and valgrind/memcheck (Was: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify@the same time) Mark Wielaard
2016-10-05 11:49                                 ` Florian Weimer
2016-10-05 12:02                                   ` Mark Wielaard
2016-10-05 14:27 ` [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time Florian Weimer
2016-10-05 15:46   ` Maxim Ostapenko
2016-10-05 16:01     ` Kostya Serebryany
2016-10-05 16:01     ` Maxim Ostapenko
2016-10-05 16:06 ` Zack Weinberg
2016-10-05 16:11   ` Kostya Serebryany
2016-10-05 16:46     ` Zack Weinberg
2016-10-05 17:58       ` Yuri Gribov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160929100429.GQ7282@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=fw@deneb.enyo.de \
    --cc=kcc@google.com \
    --cc=libc-alpha@sourceware.org \
    --cc=m.ostapenko@samsung.com \
    --cc=tetra2005@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).