Commit Graph

25 Commits

Author SHA1 Message Date
Dmitry Vyukov dfd9808b6c sanitizer_common: add simpler ThreadRegistry ctor
Currently ThreadRegistry is overcomplicated because of tsan,
it needs tid quarantine and reuse counters. Other sanitizers
don't need that. It also seems that no other sanitizer now
needs max number of threads. Asan used to need 2^24 limit,
but it does not seem to be needed now. Other sanitizers blindly
copy-pasted that without reasons. Lsan also uses quarantine,
but I don't see why that may be potentially needed.

Add a ThreadRegistry ctor that does not require any sizes
and use it in all sanitizers except for tsan.
In preparation for new tsan runtime, which won't need
any of these parameters as well.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D105713
2021-07-13 22:52:25 -07:00
Vitaly Buka b4a6fa12d1 Revert "sanitizer_common: add simpler ThreadRegistry ctor"
Breaks https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-android

This reverts commit 6062c672bc.
This reverts commit 8e489b4b96.
2021-07-12 12:04:12 -07:00
Dmitry Vyukov 8e489b4b96 sanitizer_common: add simpler ThreadRegistry ctor
Currently ThreadRegistry is overcomplicated because of tsan,
it needs tid quarantine and reuse counters. Other sanitizers
don't need that. It also seems that no other sanitizer now
needs max number of threads. Asan used to need 2^24 limit,
but it does not seem to be needed now. Other sanitizers blindly
copy-pasted that without reasons. Lsan also uses quarantine,
but I don't see why that may be potentially needed.

Add a ThreadRegistry ctor that does not require any sizes
and use it in all sanitizers except for tsan.
In preparation for new tsan runtime, which won't need
any of these parameters as well.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D105713
2021-07-11 12:36:28 +02:00
Kevin Athey 249d9b051f Revert "Remove obsolete call to AsyncSignalSafeLazyInitiFakeStack."
This reverts commit 07481b3796.

Differential Revision: https://reviews.llvm.org/D104469
2021-06-17 09:27:02 -07:00
Kevin Athey 07481b3796 Remove obsolete call to AsyncSignalSafeLazyInitiFakeStack.
Code was originally added for Myriad D46626 which was removed
with D104279.

related to: https://github.com/google/sanitizers/issues/1394

Reviewed By: vitalybuka, morehouse

Differential Revision: https://reviews.llvm.org/D104419
2021-06-16 18:26:33 -07:00
Vitaly Buka 6478ef61b1 [asan] Remove Asan, Ubsan support of RTEMS and Myriad
Differential Revision: https://reviews.llvm.org/D104279
2021-06-15 12:59:05 -07:00
Vitaly Buka 5b0e50550c [NFC][asan] Split fake_stack() into two funcions 2021-06-04 23:29:04 -07:00
Vitaly Buka 585b9679ad [NFC][asan] format ThreadStackContainsAddress 2021-06-04 23:16:43 -07:00
Dmitry Vyukov 92a3a2dc3e sanitizer_common: introduce kInvalidTid/kMainTid
Currently we have a bit of a mess related to tids:
 - sanitizers re-declare kInvalidTid multiple times
 - some call it kUnknownTid
 - implicit assumptions that main tid is 0
 - asan/memprof claim their tids need to fit into 24 bits,
   but this does not seem to be true anymore
 - inconsistent use of u32/int to store tids

Introduce kInvalidTid/kMainTid in sanitizer_common
and use them consistently.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D101428
2021-04-30 15:58:05 +02:00
Fangrui Song afec953857 [sanitizer] Simplify GetTls with dl_iterate_phdr on Linux and use it on musl/FreeBSD
... so that FreeBSD specific GetTls/glibc specific pthread_self code can be
removed. This also helps FreeBSD arm64/powerpc64 which don't have GetTls
implementation yet.

GetTls is the range of

* thread control block and optional TLS_PRE_TCB_SIZE
* static TLS blocks plus static TLS surplus

On glibc, lsan requires the range to include
`pthread::{specific_1stblock,specific}` so that allocations only referenced by
`pthread_setspecific` can be scanned.

This patch uses `dl_iterate_phdr` to collect TLS blocks. Find the one
with `dlpi_tls_modid==1` as one of the initially loaded module, then find
consecutive ranges. The boundaries give us addr and size.

This allows us to drop the glibc internal `_dl_get_tls_static_info` and
`InitTlsSize`. However, huge glibc x86-64 binaries with numerous shared objects
may observe time complexity penalty, so exclude them for now. Use the simplified
method with non-Android Linux for now, but in theory this can be used with *BSD
and potentially other ELF OSes.

This removal of RISC-V `__builtin_thread_pointer` makes the code compilable with
more compiler versions (added in Clang in 2020-03, added in GCC in 2020-07).

This simplification enables D99566 for TLS Variant I architectures.

Note: as of musl 1.2.2 and FreeBSD 12.2, dlpi_tls_data returned by
dl_iterate_phdr is not desired: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774
This can be worked around by using `__tls_get_addr({modid,0})` instead
of `dlpi_tls_data`. The workaround can be shared with the workaround for glibc<2.25.

This fixes some tests on Alpine Linux x86-64 (musl)

```
test/lsan/Linux/cleanup_in_tsd_destructor.c
test/lsan/Linux/fork.cpp
test/lsan/Linux/fork_threaded.cpp
test/lsan/Linux/use_tls_static.cpp
test/lsan/many_tls_keys_thread.cpp

test/msan/tls_reuse.cpp
```

and `test/lsan/TestCases/many_tls_keys_pthread.cpp` on glibc aarch64.

The number of sanitizer test failures does not change on FreeBSD/amd64 12.2.

Differential Revision: https://reviews.llvm.org/D98926
2021-04-15 15:34:43 -07:00
Nico Weber 0e92cbd6a6 Revert "[sanitizer] Simplify GetTls with dl_iterate_phdr on Linux"
This reverts commit ec575e3b0a.
Still doesn't work, see https://crbug.com/1196037
2021-04-05 19:00:18 -04:00
Fangrui Song ec575e3b0a [sanitizer] Simplify GetTls with dl_iterate_phdr on Linux
This was reverted by f176803ef1 due to
Ubuntu 16.04 x86-64 glibc 2.23 problems.
This commit additionally calls `__tls_get_addr({modid,0})` to work around the
dlpi_tls_data==NULL issues for glibc<2.25
(https://sourceware.org/bugzilla/show_bug.cgi?id=19826)

GetTls is the range of

* thread control block and optional TLS_PRE_TCB_SIZE
* static TLS blocks plus static TLS surplus

On glibc, lsan requires the range to include
`pthread::{specific_1stblock,specific}` so that allocations only referenced by
`pthread_setspecific` can be scanned.

This patch uses `dl_iterate_phdr` to collect TLS blocks. Find the one
with `dlpi_tls_modid==1` as one of the initially loaded module, then find
consecutive ranges. The boundaries give us addr and size.

This allows us to drop the glibc internal `_dl_get_tls_static_info` and
`InitTlsSize` entirely. Use the simplified method with non-Android Linux for
now, but in theory this can be used with *BSD and potentially other ELF OSes.

This simplification enables D99566 for TLS Variant I architectures.

See https://reviews.llvm.org/D93972#2480556 for analysis on GetTls usage
across various sanitizers.

Differential Revision: https://reviews.llvm.org/D98926
2021-04-04 15:35:53 -07:00
Nico Weber f176803ef1 Revert "[sanitizer] Simplify GetTls with dl_iterate_phdr"
This reverts commit 9be8f8b34d.
This breaks tsan on Ubuntu 16.04:

    $ cat tiny_race.c
    #include <pthread.h>
    int Global;
    void *Thread1(void *x) {
      Global = 42;
      return x;
    }
    int main() {
      pthread_t t;
      pthread_create(&t, NULL, Thread1, NULL);
      Global = 43;
      pthread_join(t, NULL);
      return Global;
    }
    $ out/gn/bin/clang -fsanitize=thread -g -O1 tiny_race.c --sysroot ~/src/chrome/src/build/linux/debian_sid_amd64-sysroot/
    $ docker run -v $PWD:/foo ubuntu:xenial /foo/a.out
    FATAL: ThreadSanitizer CHECK failed: ../../compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp:447 "((thr_beg)) >= ((tls_addr))" (0x7fddd76beb80, 0xfffffffffffff980)
        #0 <null> <null> (a.out+0x4960b6)
        #1 <null> <null> (a.out+0x4b677f)
        #2 <null> <null> (a.out+0x49cf94)
        #3 <null> <null> (a.out+0x499bd2)
        #4 <null> <null> (a.out+0x42aaf1)
        #5 <null> <null> (libpthread.so.0+0x76b9)
        #6 <null> <null> (libc.so.6+0x1074dc)

(Get the sysroot from here: https://commondatastorage.googleapis.com/chrome-linux-sysroot/toolchain/500976182686961e34974ea7bdc0a21fca32be06/debian_sid_amd64_sysroot.tar.xz)

Also reverts follow-on commits:
This reverts commit 58c62fd976.
This reverts commit 31e541e375.
2021-04-02 18:19:17 -04:00
Fangrui Song 9be8f8b34d [sanitizer] Simplify GetTls with dl_iterate_phdr
GetTls is the range of

* thread control block and optional TLS_PRE_TCB_SIZE
* static TLS blocks plus static TLS surplus

On glibc, lsan requires the range to include
`pthread::{specific_1stblock,specific}` so that allocations only referenced by
`pthread_setspecific` can be scanned.

This patch uses `dl_iterate_phdr` to collect TLS ranges. Find the one
with `dlpi_tls_modid==1` as one of the initially loaded module, then find
consecutive ranges. The boundaries give us addr and size.

This allows us to drop the glibc internal `_dl_get_tls_static_info` and
`InitTlsSize` entirely. Use the simplified method with non-Android Linux for
now, but in theory this can be used with *BSD and potentially other ELF OSes.

In the future, we can move `ThreadDescriptorSize` code to lsan (and consider
intercepting `pthread_setspecific`) to avoid hacks in generic code.

See https://reviews.llvm.org/D93972#2480556 for analysis on GetTls usage
across various sanitizers.

Differential Revision: https://reviews.llvm.org/D98926
2021-03-25 21:55:27 -07:00
Vitaly Buka 9da05cf6ed [asan] Fix pthread_create interceptor
AsanThread::Destroy implementation expected to be called on
child thread.

I missed authors concern regarding this reviewing D95184.

Reviewed By: delcypher

Differential Revision: https://reviews.llvm.org/D95731
2021-02-03 12:57:56 -08:00
Dan Liew 596d534ac3 [ASan] Stop blocking child thread progress from parent thread in `pthread_create` interceptor.
Previously in ASan's `pthread_create` interceptor we would block in the
`pthread_create` interceptor waiting for the child thread to start.

Unfortunately this has bad performance characteristics because the OS
scheduler doesn't know the relationship between the parent and child
thread (i.e. the parent thread cannot make progress until the child
thread makes progress) and may make the wrong scheduling decision which
stalls progress.

It turns out that ASan didn't use to block in this interceptor but was
changed to do so to try to address
http://llvm.org/bugs/show_bug.cgi?id=21621/.

In that bug the problem being addressed was a LeakSanitizer false
positive. That bug concerns a heap object being passed
as `arg` to `pthread_create`. If:

* The calling thread loses a live reference to the object (e.g.
  `pthread_create` finishes and the thread no longer has a live
  reference to the object).
* Leak checking is triggered.
* The child thread has not yet started (once it starts it will have a
  live reference).

then the heap object will incorrectly appear to be leaked.

This bug is covered by the `lsan/TestCases/leak_check_before_thread_started.cpp` test case.

In b029c5101f ASan was changed to block
in `pthread_create()` until the child thread starts so that `arg` is
kept alive for the purposes of leaking check.

While this change "works" its problematic due to the performance
problems it causes. The change is also completely unnecessary if leak
checking is disabled (via detect_leaks runtime option or
CAN_SANITIZE_LEAKS compile time config).

This patch does two things:

1. Takes a different approach to solving the leak false positive by
   making LSan's leak checking mechanism treat the `arg` pointer of
   created but not started threads as reachable.  This is done by
   implementing the `ForEachRegisteredThreadContextCb` callback for
   ASan.

2. Removes the blocking behaviour in the ASan `pthread_create`
   interceptor.

rdar://problem/63537240

Differential Revision: https://reviews.llvm.org/D95184
2021-01-22 23:34:43 -08:00
Drew Fisher 1e09dbb6a9 [asan] Fix stack-use-after-free checks on non-main thread on Fuchsia
While some platforms call `AsanThread::Init()` from the context of the
thread being started, others (like Fuchsia) call `AsanThread::Init()`
from the context of the thread spawning a child.  Since
`AsyncSignalSafeLazyInitFakeStack` writes to a thread-local, we need to
avoid calling it from the spawning thread on Fuchsia.  Skipping the call
here on Fuchsia is fine; it'll get called from the new thread lazily on first
attempted access.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D89607
2020-10-24 14:29:32 -07:00
Drew Fisher 29480c6c74 [asan][fuchsia] set current thread before reading thread state
When enabling stack use-after-free detection, we discovered that we read
the thread ID on the main thread while it is still set to 2^24-1.

This patch moves our call to AsanThread::Init() out of CreateAsanThread,
so that we can call SetCurrentThread first on the main thread.

Reviewed By: mcgrathr

Differential Revision: https://reviews.llvm.org/D89606
2020-10-24 14:23:09 -07:00
Martin Liska ad2be02a83 ASAN: Support detect_invalid_pointer_pairs=1 with detect_stack_use_after_return=1
Do not crash when AsanThread::GetStackVariableShadowStart does not find
a variable for a pointer on a shadow stack.

Differential Revision: https://reviews.llvm.org/D89552
2020-10-20 19:28:12 +02:00
Roland McGrath 90a10f00ff [lsan] Support LeakSanitizer runtime on Fuchsia
Support LeakSanitizer runtime on Fuchsia.

Patch By: mcgrathr

Differential Revision: https://reviews.llvm.org/D72887
2020-01-28 11:34:53 -08:00
Petr Hosek 2533bc2361 Revert "[lsan] Support LeakSanitizer runtime on Fuchsia"
This reverts commit d59e3429f3.
2020-01-28 00:24:41 -08:00
Roland McGrath d59e3429f3 [lsan] Support LeakSanitizer runtime on Fuchsia
Support LeakSanitizer runtime on Fuchsia.

Patch By: mcgrathr

Differential Revision: https://reviews.llvm.org/D72887
2020-01-27 23:35:06 -08:00
Vitaly Buka d2af368aee [compiler-rt] Remove some cpplint filters
llvm-svn: 371704
2019-09-12 02:20:36 +00:00
Vitaly Buka c0fa632236 Remove NOLINTs from compiler-rt
llvm-svn: 371687
2019-09-11 23:19:48 +00:00
Nico Weber 217222abea compiler-rt: Rename .cc file in lib/asan to .cpp
Like r367463, but for asan.

llvm-svn: 367558
2019-08-01 13:43:28 +00:00