Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.

[Kostya Serebryany <kcc@google.com>]

>> Why do you think this is very sad?  This is not a misuse of fortify
>> but rather santizers not adapting to the changing environments and
>> handling how people are treating security issues now.  Remember 10
>> years ago there was no such thing as fortification and security was
>> not treated as a first class citizen.  Now Security is treated as a
>> first class and people are requiring security before anything else.

>> Well, -D_FORTIFY_SOURCE=2 has been used heavily already 10 years ago.
>> But I certainly don't find anything sad on the fact that many programs
>> are fortified, it is a good thing.

I am sad because the current state causes other security/testing
measures to silently fail.
Fortify is a security measure for corner cases, it does not protect
from 95% of bugs that asan/etc find,
but as we see it actively hurts asan.

An unrelated sadness is caused by popular user attitude, which I've
heard several times:
"I am using Fortify, an advertised security feature, so I am safe. "
(Admittedly, this is not related to the current discussion)

>> Why do you want to put this into sanitizer_common?

I don't! I pretty much hate this idea. But do I have any other choice?

>> 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.

Yes, please.
More broadly, it would be nice if glibc had some process to test that
the sanitizers still work.
Since sanitizers are largely based on *assumptions* about how glibc
works and not on contracts,
glibc changes has broken *san a few times in the past.
My attempt (suggested by Jakub in some other discussion) to have such
a contract did not end with anything,
https://sourceware.org/glibc/wiki/ThreadPropertiesAPI, so I've never
made another attempt.
I may be asking too much here...

>> 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

Disagree. all the sanitizers will want to be directed to the original functions.
Valgrind most likely too.

>> Frankly I'm not sure why an arbitrary dynamic tool would want to
>> handle fortified APIs differently from to their unfortified
>> counterparts. It's certainly not the case for sanitizers.

Yes.

>> Well, simple dynamic redirection of fortified APIs would be enough for
>> all sanitizer tools (ASan, MSan, TSan) and probably also Valgrind. I
>> suggested that it's common across majority of dynamic tools (which
>> would justify it's centralized implementation, be it in Glibc itself

Yes.


>> or outside) but this has been debated by Jakub above.

... and I frankly don't understand why.

--kcc

On Sun, Oct 2, 2016 at 7:02 AM, Yuri Gribov <tetra2005@gmail.com> wrote:
> On Sun, Oct 2, 2016 at 10:43 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * Jakub Jelinek:
>>
>>> 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.
>
> Frankly I'm not sure why an arbitrary dynamic tool would want to
> handle fortified APIs differently from to their unfortified
> counterparts. It's certainly not the case for sanitizers.
>
>>> 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.
>>
>> Uh-oh, would you subject matter experts please come up with a
>> consistent opinion what is *actually* needed?
>>
>> Further up thread, in
>> <CAJOtW+7xjtx=DxEOSnaPfpU708RdUJYLRX8prv0bFW=x47+tmA@mail.gmail.com>,
>> Yuri Gribov said that the sanitizers will work fine despite the
>> additional indirection.
>>
>> If this is not actually true, then of course it does not make sense to
>> maintain the unfortify bits in glibc.
>
> Well, simple dynamic redirection of fortified APIs would be enough for
> all sanitizer tools (ASan, MSan, TSan) and probably also Valgrind. I
> suggested that it's common across majority of dynamic tools (which
> would justify it's centralized implementation, be it in Glibc itself
> or outside) but this has been debated by Jakub above.
>
> -Y