https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221337
Dimitry Andric <d...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |k...@freebsd.org
--- Comment #1 from Dimitry Andric <d...@freebsd.org> ---
I did a bit of further research, adding some instrumentation to ASan. In
particular, to its initialization in ClearShadowForThreadStackAndTLS() here:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/asan/asan_thread.cc#L301
and the TLS support here:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/sanitizer_common/sanitizer_linux_libcdep.cc#L358
It turns out that the beginning of its TLS area (tls_begin) is not aligned to 8
bytes anymore, after r319971:
$ asprintf.cc.tmp
==65176==DEBUG lib/asan/asan_thread.cc(228): stack_top=0x00000000,
stack_bottom=0x00000000
==65176==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(358):
segbase=0x28423a0c
==65176==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(368):
dtv[0]=0x00000002, dtv[1]=0x00000002, dtv[2]=0x284239f4
==65176==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(402):
tls_addr=0x284239f4, tls_size=0x00000018
==65176==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(407):
stack_top=0xbfbdf000, stack_bottom=0xbfbff000
==65176==DEBUG lib/asan/asan_thread.cc(235): stack_top=0xbfbdf000,
stack_bottom=0xbfbff000
==65176==DEBUG lib/asan/asan_thread.cc(292): stack_top=0xbfbdf000,
stack_bottom=0xbfbff000
==65176==DEBUG lib/asan/asan_thread.cc(296): tls_begin=0x284239f4,
tls_end=0x28423a0c
==65176==AddressSanitizer CHECK failed: lib/asan/asan_poisoning.cc:36
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
#0 0x80b5850 in __asan::AsanCheckFailed(char const*, int, char const,
unsigned long long, unsigned long long) lib/asan/asan_rtl.cc:69:3
#1 0x80c76ca in __sanitizer::CheckFailed(char const*, int, char const,
unsigned long long, unsigned long long)
lib/sanitizer_common/sanitizer_termination.cc:79:5
#2 0x80af170 in __asan::PoisonShadow(unsigned long, unsigned long, unsigned
char) lib/asan/asan_poisoning.cc:36:3
#3 0x80b7581 in ClearShadowForThreadStackAndTLS
lib/asan/asan_thread.cc:298:5
#4 0x80b7581 in __asan::AsanThread::Init(void) lib/asan/asan_thread.cc:240
#5 0x80b774d in __asan::AsanThread::ThreadStart(unsigned long,
__sanitizer::atomic_uintptr_t*) lib/asan/asan_thread.cc:249:3
#6 0x80b54c5 in __asan::AsanInitInternal(void) lib/asan/asan_rtl.cc:591:16
#7 0x807c7aa in clock_gettime
lib/sanitizer_common/sanitizer_common_interceptors.inc:1995:3
E.g in its GetTls() routine it retrieves segbase (probably from %gs), then
derives the DTV array from that, and uses the third element as the TLS base
address. In this particular case it ends up at 0x284239f4, which is not 8-byte
aligned, causing the internal CHECK failure.
In contrast, with older libc, from r319970 or before, the TLS base is aligned
to 8 bytes, whether that is by accident or on purpose, I don't know:
$ LD_LIBRARY_PATH=/usr/obj/usr/src/lib/libc.r319970 asprintf.cc.tmp
==65175==DEBUG lib/asan/asan_thread.cc(228): stack_top=0x00000000,
stack_bottom=0x00000000
==65175==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(358):
segbase=0x281212f8
==65175==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(368):
dtv[0]=0x00000002, dtv[1]=0x00000002, dtv[2]=0x281212e0
==65175==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(402):
tls_addr=0x281212e0, tls_size=0x00000018
==65175==DEBUG lib/sanitizer_common/sanitizer_linux_libcdep.cc(407):
stack_top=0xbfbdf000, stack_bottom=0xbfbff000
==65175==DEBUG lib/asan/asan_thread.cc(235): stack_top=0xbfbdf000,
stack_bottom=0xbfbff000
==65175==DEBUG lib/asan/asan_thread.cc(292): stack_top=0xbfbdf000,
stack_bottom=0xbfbff000
==65175==DEBUG lib/asan/asan_thread.cc(296): tls_begin=0x281212e0,
tls_end=0x281212f8
x1 1x
DONE
And then all the ASan machinery works fine.
I have tried to follow how the DTV array is filled, but I end up in rtld
instead of libc, so I don't fully understand how replacing libc can make a
difference in this case. Konstantin, maybe you can shed some light?
Of course I know that there is no guarantee at all for any other alignment than
4 bytes on i386, but it seems that we have somehow always managed (until now)
to align the TLS base addresses (at least for ASan's threads) to 8 bytes....
Could we do some sort of compat hack to make this work? Because after r319971,
all executables with ASan fail in the above manner, even those compiled long
ago with earlier versions of clang (and maybe even gcc).
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
