Commit Graph

13906 Commits

Author SHA1 Message Date
Vitaly Buka ea7618684c Revert "[scudo] Use require_constant_initialization"
This reverts commit 7ad4dee3e7.
2021-04-29 09:55:54 -07:00
Vitaly Buka 7ad4dee3e7 [scudo] Use require_constant_initialization
Attribute guaranties safe static initialization of globals.

Differential Revision: https://reviews.llvm.org/D101514
2021-04-29 09:47:59 -07:00
Vitaly Buka c50796475d [NFC][scudo] Suppress "division by zero" warning 2021-04-29 01:24:40 -07:00
Dmitry Vyukov d78782f6a6 tsan: fix warnings in tests
Fix format specifier.
Fix warnings about non-standard attribute placement.
Make free_race2.c test a bit more interesting:
test access with/without an offset.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D101424
2021-04-29 07:42:18 +02:00
Dmitry Vyukov aff73487c9 tsan: increase dense slab alloc capacity
We've got a user report about heap block allocator overflow.
Bump the L1 capacity of all dense slab allocators to maximum
and be careful to not page the whole L1 array in from .bss.
If OS uses huge pages, this still may cause a limited RSS increase
due to boundary huge pages, but avoiding that looks hard.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D101161
2021-04-29 07:34:50 +02:00
Roland McGrath 3341324d82 [gwp_asan] Use __sanitizer_fast_backtrace on Fuchsia
Reviewed By: phosek, cryptoad, hctim

Differential Revision: https://reviews.llvm.org/D101407
2021-04-28 16:48:14 -07:00
Vitaly Buka f7164c7714 [NFC][scudo] Add reference to a QEMU bug
D101031 added workaround for the bug.
2021-04-28 14:57:53 -07:00
Tres Popp d1e08b124c Revert "tsan: refactor fork handling"
This reverts commit e1021dd1fd.
2021-04-28 14:08:33 +02:00
Alex Richardson 777ca513c8 [builtins] Fix ABI-incompatibility with GCC for floating-point compare
While implementing support for the float128 routines on x86_64, I noticed
that __builtin_isinf() was returning true for 128-bit floating point
values that are not infinite when compiling with GCC and using the
compiler-rt implementation of the soft-float comparison functions.
After stepping through the assembly, I discovered that this was caused by
GCC assuming a sign-extended 64-bit -1 result, but our implementation
returns an enum (which then has zeroes in the upper bits) and therefore
causes the comparison with -1 to fail.

Fix this by using a CMP_RESULT typedef and add a static_assert that it
matches the GCC soft-float comparison return type when compiling with GCC
(GCC has a __libgcc_cmp_return__ mode that can be used for this purpose).

Also move the 3 copies of the same code to a shared .inc file.

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D98205
2021-04-28 12:19:19 +01:00
Vitaly Buka b1a77e465e [scudo] Enable arm32 arch 2021-04-27 18:35:45 -07:00
Dmitry Vyukov f69853ac40 tsan: fix build with COMPILER_RT_TSAN_DEBUG_OUTPUT
COMPILER_RT_TSAN_DEBUG_OUTPUT enables TSAN_COLLECT_STATS,
which changes layout of runtime structs (some structs contain
stats when the option is enabled).
It's not OK to build runtime with the define, but tests without it.
The error is detected by build_consistency_stats/nostats.
Fix this by defining TSAN_COLLECT_STATS for tests to match the runtime.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D101386
2021-04-27 22:38:56 +02:00
Dmitry Vyukov e1021dd1fd tsan: refactor fork handling
Commit efd254b636 ("tsan: fix deadlock in pthread_atfork callbacks")
fixed another deadlock related to atfork handling.
But builders with DCHECKs enabled reported failures of
pthread_atfork_deadlock2.c and pthread_atfork_deadlock3.c tests
related to the fact that we hold runtime locks on interceptor exit:
https://lab.llvm.org/buildbot/#/builders/70/builds/6727
This issue is somewhat inherent to the current approach,
we indeed execute user code (atfork callbacks) with runtime lock held.

Refactor fork handling to not run user code (atfork callbacks)
with runtime locks held. This change does this by installing
own atfork callbacks during runtime initialization.
Atfork callbacks run in LIFO order, so the expectation is that
our callbacks run last, right before the actual fork.
This way we lock runtime mutexes around fork, but not around
user callbacks.

Extend tests to also install after fork callbacks just to cover
more scenarios. Some tests also started reporting real races
that we previously suppressed.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D101385
2021-04-27 22:37:27 +02:00
Evgenii Stepanov 5275d772da Revert "tsan: fix deadlock in pthread_atfork callbacks"
Tests fail on debug builders. See the forward fix in
https://reviews.llvm.org/D101385.

This reverts commit efd254b636.
2021-04-27 12:36:31 -07:00
Evgenii Stepanov 561f4b9087 Fix -Wunused-but-set-variable warning in msan_test.cpp 2021-04-27 12:07:13 -07:00
Vitaly Buka 0e6f934cc3 [NFC][lsan] Another attempt to fix arm bot 2021-04-27 10:46:36 -07:00
Dmitry Vyukov efd254b636 tsan: fix deadlock in pthread_atfork callbacks
We take report/thread_registry locks around fork.
This means we cannot report any bugs in atfork handlers.
We resolved this by enabling per-thread ignores around fork.
This resolved some of the cases, but not all.
The added test triggers a race report from a signal handler
called from atfork callback, we reset per-thread ignores
around signal handlers, so we tried to report it and deadlocked.
But there are more cases: a signal handler can be called
synchronously if it's sent to itself. Or any other report
types would cause deadlocks as well: mutex misuse,
signal handler spoiling errno, etc.
Disable all reports for the duration of fork with
thr->suppress_reports and don't re-enable them around
signal handlers.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D101154
2021-04-27 13:25:26 +02:00
Vitaly Buka 3c47f5f46e [asan][NFC] Fix "not used" warning in test 2021-04-26 20:07:20 -07:00
Leonard Chan a786f2badc [compiler-rt][hwasan] Add definition for Symbolizer::SymbolizeFrame
This is undefined if SANITIZER_SYMBOLIZER_MARKUP is 1, which is the case for
Fuchsia, and will result in a undefined symbol error. This function is needed
by hwasan for online symbolization, but is not needed for us since we do
offline symbolization.

Differential Revision: https://reviews.llvm.org/D99386
2021-04-26 13:25:10 -07:00
Vitaly Buka 337a024bba [scudo][NFC] Fix cast warning 2021-04-25 15:47:28 -07:00
Vitaly Buka 98a7563261 [scudo] Mark ARM64 as supported platform 2021-04-25 15:47:28 -07:00
Vitaly Buka 51b4a7ef52 [sanitizer] Use COMPILER_RT_EMULATOR with gtests
Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D100998
2021-04-25 15:41:13 -07:00
Lang Hames 5e537ea1d7 [ORC-RT] Re-apply "Initial ORC Runtime directories and build..." with fixes.
This reapplies 1e1d75b190, which was reverted in ce1a4d5323 due to build
failures.

The unconditional dependencies on clang and llvm-jitlink in
compiler-rt/test/orc/CMakeLists.txt have been removed -- they don't appear to
be necessary, and I suspect they're the cause of the build failures seen
earlier.
2021-04-24 16:00:20 -07:00
Lang Hames ce1a4d5323 Revert "[ORC-RT] Initial ORC Runtime directories and build system files."
Some builders failed with a missing clang dependency. E.g.

CMake Error at /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build \
  /lib/cmake/llvm/AddLLVM.cmake:1786 (add_dependencies):
The dependency target "clang" of target "check-compiler-rt" does not exist.

Reverting while I investigate.

This reverts commit 1e1d75b190.
2021-04-23 20:36:59 -07:00
Lang Hames 1e1d75b190 [ORC-RT] Initial ORC Runtime directories and build system files.
This patch contains initial directories and build files for the ORC runtime.

Differential Revision: https://reviews.llvm.org/D100711
2021-04-23 20:21:22 -07:00
Mitch Phillips 643ccf6e4b Revert "[Scudo] Use GWP-ASan's aligned allocations and fixup postalloc hooks."
This reverts commit a683abe5c0.

Broke the upstream buildbots:
https://lab.llvm.org/buildbot/#/builders/37/builds/3731/steps/16/logs/stdio
2021-04-23 15:40:38 -07:00
Peter Collingbourne f2819ee6cc scudo: Work around gcc 8 conversion warning.
Should fix:
https://lab.llvm.org/buildbot#builders/99/builds/2953
2021-04-23 11:26:12 -07:00
Mitch Phillips f1a47181f5 [hwasan] Remove untagging of kernel-consumed memory
Now that page aliasing for x64 has landed, we don't need to worry about
passing tagged pointers to libc, and thus D98875 removed it.
Unfortunately, we still test on aarch64 devices that don't have the
kernel tagged address ABI (https://reviews.llvm.org/D98875#2649269).

All the memory that we pass to the kernel in these tests is from global
variables. Instead of having architecture-specific untagging mechanisms
for this memory, let's just not tag the globals.

Reviewed By: eugenis, morehouse

Differential Revision: https://reviews.llvm.org/D101121
2021-04-23 11:04:36 -07:00
Mitch Phillips a683abe5c0 [Scudo] Use GWP-ASan's aligned allocations and fixup postalloc hooks.
This patch does a few cleanup things:
 1. The non-standalone scudo has a problem where GWP-ASan allocations
 may not meet alignment requirements where Scudo was requested to have
 alignment >= 16. Use the new GWP-ASan API to fix this.
 2. The standalone variant loses some debugging information inside of
 GWP-ASan because we ask GWP-ASan to allocate an aligned size in the
 frontend. This means reports end up with 'UaF on a 16-byte allocation'
 for a 1-byte allocation with 16-byte alignment. Also use the new API to
 fix this.
 3. Add post-alloc hooks for GWP-ASan intercepted allocations, and add
 stats tracking for GWP-ASan allocations.
 4. Add a small test that checks the alignment of the frontend
 allocator, so that it can be used under GWP-ASan torture mode.
 5. Add GWP-ASan torture mode as a testing configuration to catch these
 regressions.

Depends on D94830, D95889.

Reviewed By: cryptoad

Differential Revision: https://reviews.llvm.org/D95884
2021-04-23 10:07:36 -07:00
Peter Collingbourne 0a5576ecf0 scudo: Store header on deallocation before retagging memory.
From a cache perspective it's better to store the header immediately
after loading it. If we delay this operation until after we've
retagged it's more likely that our header will have been evicted from
the cache and we'll need to fetch it again in order to perform the
compare-exchange operation.

For similar reasons, store the deallocation stack before retagging
instead of afterwards.

Differential Revision: https://reviews.llvm.org/D101137
2021-04-23 09:32:16 -07:00
Vitaly Buka a062140a9e [NFC] Suppress cpplint warning in test 2021-04-22 20:20:52 -07:00
Vitaly Buka 619ecba5bc [NFC] Fix cpplint warning 2021-04-22 19:05:20 -07:00
Peter Collingbourne 484b6648fd scudo: Only static_assert for compressed LSB format with clang.
It looks like there's some old version of gcc that doesn't like this
static_assert (I couldn't reproduce the issue with gcc 8, 9 or 10).
Work around the issue by only checking the static_assert under clang,
which should provide sufficient coverage.

Should hopefully fix this buildbot:
https://lab.llvm.org/buildbot/#/builders/112/builds/5356
2021-04-22 16:11:52 -07:00
Peter Collingbourne a6500b013a scudo: Optimize getSizeLSBByClassId() by compressing the table into an integer if possible. NFCI.
With AndroidSizeClassMap all of the LSBs are in the range 4-6 so we
only need 2 bits of information per size class. Furthermore we have
32 size classes, which conveniently lets us fit all of the information
into a 64-bit integer. Do so if possible so that we can avoid a table
lookup entirely.

Differential Revision: https://reviews.llvm.org/D101105
2021-04-22 15:33:29 -07:00
Peter Collingbourne 4e88e5877c scudo: Use a table to look up the LSB for computing the odd/even mask. NFCI.
In the most common case we call computeOddEvenMaskForPointerMaybe()
from quarantineOrDeallocateChunk(), in which case we need to look up
the class size from the SizeClassMap in order to compute the LSB. Since
we need to do a lookup anyway, we may as well look up the LSB itself
and avoid computing it every time.

While here, switch to a slightly more efficient way of computing the
odd/even mask.

Differential Revision: https://reviews.llvm.org/D101018
2021-04-22 11:19:55 -07:00
Vitaly Buka 686328263e Revert "[sanitizer] Use COMPILER_RT_EMULATOR with gtests"
Missed review comments.

This reverts commit e25082961c.
2021-04-22 11:15:55 -07:00
Vitaly Buka d423509b80 [scudo] Check if MADV_DONTNEED zeroes memory
QEMU just ignores MADV_DONTNEED
b1cffefa1b/linux-user/syscall.c (L11941)

Depends on D100998.

Differential Revision: https://reviews.llvm.org/D101031
2021-04-22 10:40:18 -07:00
Vitaly Buka e25082961c [sanitizer] Use COMPILER_RT_EMULATOR with gtests
Differential Revision: https://reviews.llvm.org/D100998
2021-04-22 10:33:50 -07:00
Vitaly Buka 149d5a8c47 [lsan] Temporarily disable new check broken on arm7 2021-04-22 10:05:02 -07:00
Jianzhou Zhao 7fdf270965 [dfsan] Track origin at loads
The first version of origin tracking tracks only memory stores. Although
    this is sufficient for understanding correct flows, it is hard to figure
    out where an undefined value is read from. To find reading undefined values,
    we still have to do a reverse binary search from the last store in the chain
    with printing and logging at possible code paths. This is
    quite inefficient.

    Tracking memory load instructions can help this case. The main issues of
    tracking loads are performance and code size overheads.

    With tracking only stores, the code size overhead is 38%,
    memory overhead is 1x, and cpu overhead is 3x. In practice #load is much
    larger than #store, so both code size and cpu overhead increases. The
    first blocker is code size overhead: link fails if we inline tracking
    loads. The workaround is using external function calls to propagate
    metadata. This is also the workaround ASan uses. The cpu overhead
    is ~10x. This is a trade off between debuggability and performance,
    and will be used only when debugging cases that tracking only stores
    is not enough.

Reviewed By: gbalats

Differential Revision: https://reviews.llvm.org/D100967
2021-04-22 16:25:24 +00:00
Peter Collingbourne e4fa0b307f scudo: Obtain tag from pointer instead of loading it from memory. NFCI.
Since we already have a tagged pointer available to us, we can just
extract the tag from it and avoid an LDG instruction.

Differential Revision: https://reviews.llvm.org/D101014
2021-04-21 21:47:49 -07:00
Matt Morehouse 3511022f5f [HWASan] Untag argument to __hwasan_tag_memory.
__hwasan_tag_memory expects untagged pointers, so make sure our pointer
is untagged.
2021-04-21 17:08:43 -07:00
Peter Collingbourne 3d47e003e9 scudo: Make prepareTaggedChunk() and resizeTaggedChunk() generic.
Now that we have a more efficient implementation of storeTags(),
we should start using it from resizeTaggedChunk(). With that, plus
a new storeTag() function, resizeTaggedChunk() can be made generic,
and so can prepareTaggedChunk(). Make it so.

Now that the functions are generic, move them to combined.h so that
memtag.h no longer needs to know about chunks.

Differential Revision: https://reviews.llvm.org/D100911
2021-04-21 13:53:39 -07:00
Peter Collingbourne 46c59d91dc scudo: Use DC GZVA instruction in storeTags().
DC GZVA can operate on multiple granules at a time (corresponding to
the CPU's cache line size) so we can generally expect it to be faster
than STZG in a loop.

Differential Revision: https://reviews.llvm.org/D100910
2021-04-21 13:53:26 -07:00
Roland McGrath d9b2641aa5 [scudo] Avoid empty statement warnings
An empty macro that expands to just `... else ;` can get
warnings from some compilers (e.g. GCC's -Wempty-body).

Reviewed By: cryptoad, vitalybuka

Differential Revision: https://reviews.llvm.org/D100693
2021-04-21 12:39:09 -07:00
Emily Shi 6ae7fc0a29 [compiler-rt] check max address from kernel is <= mmap range size
If these sizes do not match, asan will not work as expected. Previously, we added compile-time checks for non-iOS platforms. We check at run time for iOS because we get the max VM size from the kernel at run time.

rdar://76477969

Reviewed By: delcypher

Differential Revision: https://reviews.llvm.org/D100784
2021-04-21 12:02:48 -07:00
Vitaly Buka 5e9e463e1f [lsan] Test to show lsan dependency on globals
This test from @MaskRay comment on D69428. The patch is looking to
break this behavior. If we go with D69428 I hope we will have some
workaround for this test or include explicit test update into the patch.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D100906
2021-04-20 22:00:26 -07:00
Fangrui Song 031c40dc3c [sanitizer] Fix glibc sparc build and add GetTls support
sanitizer_linux_libcdep.cpp doesn't build for Linux sparc (with minimum support
but can build) after D98926. I wasn't aware because the file didn't mention
`__sparc__`.

While here, add the relevant support since it does not add complexity
(the D99566 approach).  Adds an explicit `#error` for unsupported
non-Android Linux and FreeBSD architectures.

ThreadDescriptorSize is only used by lsan to scan thread-specific data keys in
the thread control block.

On TLS Variant II architectures (i386/x86_64/s390/sparc), our dl_iterate_phdr
based approach can cover the region from the first byte of the static TLS block
(static TLS surplus) to the thread pointer.
We just need to extend the range to include the first few members of struct
pthread. offsetof(struct pthread, specific_used) satisfies the requirement and
has not changed since 2007-05-10. We don't need to update ThreadDescriptorSize
for each glibc version.

Technically we could use the 524/1552 for x86_64 as well but there is potential
risk that large applications with thousands of shared object dependency may
dislike the time complexity increase if there are many threads, so I don't make
the simplification for now.

Differential Revision: https://reviews.llvm.org/D100892
2021-04-20 17:42:41 -07:00
Dan Liew 6f4f0afaa8 [Compiler-rt] Fix bug when considering CMake path returned by llvm-config.
The previous check was wrong because it only checks that the LLVM CMake
directory exists. However, it's possible that the directory exists but
the `LLVMConfig.cmake` file does not. When this happens we would
incorectly try to include the non-existant file.

To fix this we make the check stricter by checking that the file
we want to include actually exists.

This is a follow up to fd28517d87.

rdar://76870467
2021-04-20 11:57:20 -07:00
Evgenii Stepanov fbb9132e71 Fix android-x86 library name in asan_device_setup.
https://reviews.llvm.org/D26764 removed i686 variants of compiler-rt
libraries and canonicalized the i386 name.

https://reviews.llvm.org/D37278 partially reverted the previous change
to keep i686 name on Android, but did not update asan_device_setup
script.

This changes fixes asan_device_setup.

Differential Revision: https://reviews.llvm.org/D100505
2021-04-19 17:39:58 -07:00
Emily Shi cc2b62a06e [compiler-rt] assert max virtual address is <= mmap range size
If these sizes do not match, asan will not work as expected.

If possible, assert at compile time that the vm size is less than or equal to mmap range.
If a compile time assert is not possible, check at run time (for iOS)

rdar://76477969

Reviewed By: delcypher, yln

Differential Revision: https://reviews.llvm.org/D100239
2021-04-19 14:01:07 -07:00