POSIX timer can be configured to send any kind of signal, however, it
fundamentally does not make sense to consider a timer a synchronous
signal. Teach TSan that timers are never synchronous.
The tricky bit here is correctly defining compiler-rt's siginfo
replacement, which is a rather complex struct. Extend it in a limited
way that is mostly cross-platform compatible and add offset tests in
sanitizer_platform_limits_posix.cpp.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D142117
In LLVM the MachOPlatform class is modified to identify unwind info sections
and the address ranges of the functions these sections cover. These address
ranges are then communicated to the ORC runtime by attaching them to the
register-object-platform-sections allocation action.
In the ORC runtime the unwind-info section addresses are recorded and used to
support lookup of unwind info via the new `findDynamicUnwindSections` function.
At bootstrap time the ORC runtime checks for the presence of new
unwind-info-lookup-registration functions in libunwind (see
https://reviews.llvm.org/D142176), and if available uses them to register the
`findDynamicUnwindSections` function with libunwind to enable callback-based
lookup. If the new unwind-info-lookup-registration functions are not available
then the ORC runtime falls back to using the existing libunwind registration
APIs.
The callback-based scheme is intended to address three shortcomings in the
current registration scheme for JIT'd unwind info on Darwin: (1) Lack of
compact-unwind support, (2) inability to describe the subarchitecture of JIT'd
frames, and (3) lack of efficient address-based lookup data structures in
libunwind.
For more details see the proposed libunwind changes in
https://reviews.llvm.org/D142176.
Lines with 'record_addr:' are not processed when failing to decode
access tag. The regular format is: %02x/%02x but for a short tag it's:
%02x/%02x(%02x). Now it will handle both cases.
Tested-by: Ivar Henckel <ivar.henckel@sony.com>
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D141906
Unlike asan, we can't use pointer arithmetics to get from user ptr to
metadata. Asan does not use CombinedAllocator::GetMetadata and store
metadata next to the user data.
This patch removes the static ubsan runtime on Apple devices. The motivation
is to reduce the toolchain size.
rdar://102061519
Differential Revision: https://reviews.llvm.org/D141550
IntervalMap is an optionally-coalescing map -- it uses half-open ranges as keys,
allows lookups based on elements of the ranges (returning an iterator to the
containing range) and optionally coalesces adjacent ranges that have the same
value.
IntervalSet is an optionally-coalescing set based on IntervalMap.
These collections will be used to store and lookup metadata section ranges,
e.g. unwind-info ranges.
The GWP-ASan recoverable mode allows a process to continue to function
after a GWP-ASan error is detected. The error will continue to be
dumped, but GWP-ASan now has APIs that a signal handler (like the
example optional crash handler) can call in order to allow the
continuation of a process.
When an error occurs with an allocation, the slot used for that
allocation will be permanently disabled. This means that free() of that
pointer is a no-op, and use-after-frees will succeed (writing and
reading the data present in the page).
For heap-buffer-overflow/underflow, the guard page is marked as accessible
and buffer-overflows will succeed (writing and reading the data present
in the now-accessible guard page). This does impact adjacent
allocations, buffer-underflow and buffer-overflows from adjacent
allocations will no longer touch an inaccessible guard page. This could
be improved in future by having two guard pages between each adjacent
allocation, but that's out of scope of this patch.
Each allocation only ever has a single error report generated. It's
whatever came first between invalid-free, double-free, use-after-free or
heap-buffer-overflow, but only one.
Reviewed By: eugenis, fmayer
Differential Revision: https://reviews.llvm.org/D140173
The aarch64 39- and 42-bit mappings were broken: mappings to meta and shadow were not fully invertible. This CL introduces a working set of mappings, and also increases the size of some app regions:
* aarch64, 39-bit (2^39 == 512GB):
- Low: (Old) 4GB -> (New) 20GB
- Mid: 4GB -> 20GB
- Heap: 4GB -> 12GB
- High: 8GB -> 12GB
* aarch64, 42-bit (2^42 == 4TB):
- Low: 64GB -> 128GB
- Mid: 4GB -> 88GB
- Heap: 64GB -> 192GB
- High: 64GB
Additionally, this CL improves the code comments for all the linux aarch64 mappings.
Differential Revision: https://reviews.llvm.org/D141640
When building/testing ASan inside the GCC tree on Solaris while using GNU
`ld` instead of Solaris `ld`, a large number of tests SEGVs on both sparc
and x86 like this:
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t>
(a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at
sanitizer_common/sanitizer_atomic_clang_x86.h:46
46 v = a->val_dont_use;
1: x/i $pc
=> 0xfe014cfc
<_ZN11__sanitizer11atomic_loadINS_16atomic_uintptr_tEEENT_4TypeEPVKS2_NS_12memory_orderE+62>:
mov (%eax),%eax
(gdb) bt
#0 0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t>
(a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at
sanitizer_common/sanitizer_atomic_clang_x86.h:46
#1 0xfe0bd1d7 in __sanitizer::DTLS_NextBlock (cur=0xfc602a58) at
sanitizer_common/sanitizer_tls_get_addr.cpp:53
#2 0xfe0bd319 in __sanitizer::DTLS_Find (id=1) at
sanitizer_common/sanitizer_tls_get_addr.cpp:77
#3 0xfe0bd466 in __sanitizer::DTLS_on_tls_get_addr (arg_void=0xfeffd068,
res=0xfe602a18, static_tls_begin=0, static_tls_end=0) at
sanitizer_common/sanitizer_tls_get_addr.cpp:116
#4 0xfe063f81 in __interceptor___tls_get_addr (arg=0xfeffd068) at
sanitizer_common/sanitizer_common_interceptors.inc:5501
#5 0xfe0a3054 in __sanitizer::CollectStaticTlsBlocks (info=0xfeffd108,
size=40, data=0xfeffd16c) at
sanitizer_common/sanitizer_linux_libcdep.cpp:366
#6 0xfe6ba9fa in dl_iterate_phdr () from /usr/lib/ld.so.1
#7 0xfe0a3132 in __sanitizer::GetStaticTlsBoundary (addr=0xfe608020,
size=0xfeffd244, align=0xfeffd1b0) at
sanitizer_common/sanitizer_linux_libcdep.cpp:382
#8 0xfe0a33f7 in __sanitizer::GetTls (addr=0xfe608020, size=0xfeffd244)
at sanitizer_common/sanitizer_linux_libcdep.cpp:482
#9 0xfe0a34b1 in __sanitizer::GetThreadStackAndTls (main=true,
stk_addr=0xfe608010, stk_size=0xfeffd240, tls_addr=0xfe608020,
tls_size=0xfeffd244) at sanitizer_common/sanitizer_linux_libcdep.cpp:565
The address being accessed is unmapped. However, even when the tests
`PASS` with Solaris `ld`, `ASAN_OPTIONS=verbosity=2` shows
==6582==__tls_get_addr: Can't guess glibc version
Given that that the code is stricly `glibc`-specific according to
`sanitizer_tls_get_addr.h`, there seems little point in using the
interceptor on non-`glibc` targets.
That's what this patch does. Tested on `i386-pc-solaris2.11` and
`sparc-sun-solaris2.11` inside the GCC tree.
Differential Revision: https://reviews.llvm.org/D141385
R_RISCV_JAL referencing a preemptible symbol is disallowed with ld.lld and binutils 2.40 (https://sourceware.org/PR28509)
riscv64-yoe-linux-ld: relocation R_RISCV_JAL against `__interceptor_sigsetjmp' which may bind externally can not be used when making a shared object; recompile with -fPIC
Reviewed By: kito-cheng, MaskRay
Differential Revision: https://reviews.llvm.org/D141656
This patch modifies the MachOPlatform bootstrap process to record allocation
actions for ORC runtime platform support code in a "deferred actions" vector
rather than attaching it to the corresponding LinkGraphs up-front. The deferred
allocation-actions are run after all the platform support code has been loaded
by attaching them to a separate "bootstrap-complete" graph.
This change should allow the mach-o platform support code in the ORC runtime to
use advanced mach-o platform features (e.g. static inits, TLVs), provided that
the support code does not use these features at runtime before the bootstrap
process completes, or after the shutdown process starts. This is a nice
improvement in and of itself but is motivated by specific future plans: we
want to start recording unwind info in the mach-o platform state object*, and
the recording functions will have their own frame info that needs registering.
The deferred allocation-actions scheme allows for this.
* The plan is to add a new unwind-info-lookup path to libunwind to allow it to
call back to the ORC runtime to find unwind sections. This will simplify the
implementation of support for JIT'd compact-unwind info.
Update: A change to this code recently broke our bots after this change enabled the 64 bit allocator for defined(aarch64): https://reviews.llvm.org/D137136
We added logic initially to get our test passing, but want to further clean up this code to enable MacOS to use allocator64 and increase readability and clarity of the logic.
rdar://103647896
Differential Revision: https://reviews.llvm.org/D141171
Main goal is to remove thread registry dependency from the interface because HWASAN is using its own code to manage threads.
Reviewed By: vitalybuka, kstoimenov
Differential Revision: https://reviews.llvm.org/D140039
Breaks bots.
Also it's missing changes we discussed on review.
This reverts commit f001e50f955c3cdf2deb79e38a9fd19c9a781882.
This reverts commit 2924189233fdb724453ead4b94595107b1ce9cfa.
Main goal is to remove thread registry dependency from the interface because HWASAN is using its own code to manage threads.
Reviewed By: vitalybuka, kstoimenov
Differential Revision: https://reviews.llvm.org/D140039
Several map implementations require that map calls provide a page
aligned size.
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D141630
This is so we can increase the buffer size for finding elusive bugs.
Tested by hand with this program
```
int main(int argc, char** argv) {
if (argc < 2)
return 1;
int n = atoi(argv[1]);
char* x = reinterpret_cast<char*>(malloc(1));
*((volatile char*)x) = 1;
free(x);
for (; n > 0; --n) {
char* y = reinterpret_cast<char*>(malloc(1024));
*((volatile char*)y) = 1;
free(y);
}
*x = 2;
return 0;
}
```
SCUDO_OPTIONS=allocation_ring_buffer_size=30000 ./uaf 1000000
-> no allocation trace
SCUDO_OPTIONS=allocation_ring_buffer_size=30000000 ./uaf 1000000
-> allocation trace
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D140932
The GWP-ASan recoverable mode allows a process to continue to function
after a GWP-ASan error is detected. The error will continue to be
dumped, but GWP-ASan now has APIs that a signal handler (like the
example optional crash handler) can call in order to allow the
continuation of a process.
When an error occurs with an allocation, the slot used for that
allocation will be permanently disabled. This means that free() of that
pointer is a no-op, and use-after-frees will succeed (writing and
reading the data present in the page).
For heap-buffer-overflow/underflow, the guard page is marked as accessible
and buffer-overflows will succeed (writing and reading the data present
in the now-accessible guard page). This does impact adjacent
allocations, buffer-underflow and buffer-overflows from adjacent
allocations will no longer touch an inaccessible guard page. This could
be improved in future by having two guard pages between each adjacent
allocation, but that's out of scope of this patch.
Each allocation only ever has a single error report generated. It's
whatever came first between invalid-free, double-free, use-after-free or
heap-buffer-overflow, but only one.
Reviewed By: eugenis, fmayer
Differential Revision: https://reviews.llvm.org/D140173
