[PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
Florian Weimer
fweimer@redhat.com
Tue Sep 6 09:51:00 GMT 2016
On 09/06/2016 11:20 AM, Yuri Gribov wrote:
> But isn't it the same with Valgrind - it doesn't play nice with
> sanitizers (because both tools are far too complicated) but noone
> really cares to fix this and just people just perform separate
> verification runs.
Sure, we can pile workarounds on workarounds, but we get maintenance
problems (like the dlsym error reporting change which broke ASan earlier
this year), and misleading results because the interceptors do not
correctly model the glibc behavior.
For example, the following program has a data race on glibc, but not on
other libcs, and the interceptors appear to assume the other libc's
behavior, and -fsanitize=thread does not report anything.
#include <pthread.h>
#include <stdbool.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
__attribute__ ((noinline, noclone))
static void
check_value (const char *s, int expected)
{
int actual;
if (sscanf (s, "Unknown error %d", &actual) != 1)
{
printf ("error: scanf parsing failed: [[%s]]\n", s);
_exit (1);
}
if (actual != expected)
{
printf ("error: scanf returned wrong value\n");
printf ("error: expected: %d\n", expected);
printf ("error: actual: %d\n", actual);
_exit (1);
}
}
static void *
thread_func (void *closure)
{
int *pval = closure;
while (true)
{
check_value (strerror (*pval), *pval);
}
return NULL;
}
int
main ()
{
int val1000 = 1000;
pthread_t thr;
if (pthread_create (&thr, NULL, thread_func, &val1000) != 0)
abort ();
int val9999 = 9999;
thread_func (&val9999);
}
This also applies to the NSS functions (such as getpwuid) and the locale
handling. All these data races are currently obscured by the
interceptors, I think. We can fix the strerror and getpwuid races with
more TLS data, but for locale, it's not really an option.
Florian
More information about the Libc-alpha
mailing list