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

[Andrew Pinski <pinskia at gmail dot com>]

On Mon, Sep 5, 2016 at 10:27 AM, Maxim Ostapenko
<m.ostapenko@samsung.com> wrote:
> Hi!
>
> When fortify is used with MSan it will cause MSan false positives.
>
> #include <stdio.h>
> #include <string.h>
> int main()
> {
>         char text[100];
>         sprintf(text, "hello");
>         printf("%lu\n", strlen(text));
> }
>
> % clang test.c -fsanitize=memory   -O3 && ./a.out
> 5
> % clang test.c -fsanitize=memory -D_FORTIFY_SOURCE=2  -O3 && ./a.out
> Uninitialized bytes in __interceptor_strlen at offset 0 inside
> [0x7ffe259e4d20, 6)
> ==26297==WARNING: MemorySanitizer: use-of-uninitialized-value
>     #0 0x4869cc in main
>
> With ASan, this will not cause false positives, but may case false negatives
> or just confuse people with "wrong" reports when fortify catches the error.
>
> Although fortify is good thing as it (and it's enabled by default on some
> major distros e.g. Ubuntu and Gentoo), people still complain about {A, M}San
> vs fortify interaction, see e.g.
> https://github.com/google/sanitizers/issues/689. One possible solution would
> be to extend {A, M}San to support foo_chk() functions, but this would
> increase the complexity of sanitizer tools with quite small benefit. Another
> choice would be to warn users when they compile their code with {A, M, T}San
> and fortify enabled.


This is the only solution in my mind.  And it does not expand the
complexity as much as complex as the Sanitizers already complex and
needs a lot of porting to new target already.

Thanks,
Andrew

>
> This patch implements the second approach. The simplest way to warn is to
> modify the Glibc headers to check if fortify and one of the sanitizers is
> enabled. Does this look reasonable?
>
> I've tried to add a testcase for new warning into Glibc testsuite, but
> failed to see how exactly I can do it. Does Glibc have some framework for
> compilation tests? Could someone help me with this issue?
> For now, I've tested this patch locally with GCC 4.8, fresh GCC and fresh
> Clang on my Ubuntu box:
>
> gcc test.c -fsanitize=address -D_FORTIFY_SOURCE=2  -O3 -L${SYSROOT}/usr/lib
> -I${SYSROOT}/include -Wl,-rpath=${SYSROOT}/lib
> -Wl,--dynamic-linker=${SYSROOT}/lib/ld-2.24.90.so  -S
> In file included from
> /home/max/install/glibc//include/bits/libc-header-start.h:33:0,
>                  from /home/max/install/glibc//include/stdio.h:28,
>                  from test.c:1:
> /home/max/install/glibc//include/features.h:374:3: warning: #warning
> _FORTIFY_SOURCE is not compatible with sanitizer [-Wcpp]
>  # warning _FORTIFY_SOURCE is not compatible with sanitizer
>
>
> ~/install/master/bin/gcc test.c -fsanitize=address -D_FORTIFY_SOURCE=2  -O3
> -L${SYSROOT}/usr/lib -I${SYSROOT}/include -Wl,-rpath=${SYSROOT}/lib
> -Wl,--dynamic-linker=${SYSROOT}/lib/ld-2.24.90.so  -S
> In file included from
> /home/max/install/glibc//include/bits/libc-header-start.h:33:0,
>                  from /home/max/install/glibc//include/stdio.h:28,
>                  from test.c:1:
> /home/max/install/glibc//include/features.h:374:3: warning: #warning
> _FORTIFY_SOURCE is not compatible with sanitizer [-Wcpp]
>  # warning _FORTIFY_SOURCE is not compatible with sanitizer
>
> clang  test.c -fsanitize=address -D_FORTIFY_SOURCE=2  -O3
> -L${SYSROOT}/usr/lib -I${SYSROOT}/include -Wl,-rpath=${SYSROOT}/lib
> -Wl,--dynamic-linker=${SYSROOT}/lib/ld-2.24.90.so
> In file included from test.c:1:
> In file included from /home/max/install/glibc//include/stdio.h:28:
> In file included from
> /home/max/install/glibc//include/bits/libc-header-start.h:33:
> /home/max/install/glibc//include/features.h:374:3: warning: _FORTIFY_SOURCE
> is not compatible with sanitizer [-W#warnings]
> # warning _FORTIFY_SOURCE is not compatible with sanitizer
>   ^
> 1 warning generated.
>
>
> -Maxim