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
Track min/max/avg access density (accesses per byte and accesses per
byte per lifetime second) metrics directly during profiling. This allows
more accurate use of these metrics in profile analysis and use, instead
of trying to compute them from already aggregated data in the profile.
This required regenerating some of the raw profile and executable inputs
for a few tests. While here, make the llvm-profdata memprof tests more
resilient to differences in things like memory mapping, timestamps and
cpu ids to make future test updates easier.
Differential Revision: https://reviews.llvm.org/D141558
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
In many cases, we can use an alias to avoid a symbolic relocations,
instead of using the public, interposable symbol. When the instrumented
function is in a COMDAT, we can use a hidden alias, and still avoid
references to discarded sections.
Previous versions of this patch allowed the compiler to name the
generated alias, but that would only be valid when the functions were
local. Since the alias may be used across TUs we use a more
deterministic naming convention, and add a .local suffix to the alias
name just as we do for relative vtables aliases.
This should be safe to land after an incorrect LLD assertion was removed
in https://reviews.llvm.org/rG20894a478da224bdd69c91a22a5175b28bc08ed9
which caused assertion failures in LLD on Mac.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D137982
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
This fills in a gap in the tsan_shadow_test coverage:
it is possible that the meta regions are aliased
(e.g., the heap meta region overlaps the high app meta
region). Indeed, the Aarch64_39 mapping has been
silently broken in this way for quite some time.
This CL checks whether the individual meta regions
(for low/mid/high/heap) overlap. Note that
(!kBrokenAliasedMetas && !kBrokenLinearity) implies
that MemToMeta is invertible; we cannot directly
test MetaToMem because that function does not exist.
Differential Revision: https://reviews.llvm.org/D141445
This patch enables sanitizer common unit tests for arm64 architecture only on apple devices.
It also lowers the expected compression ratio for 64 bit machines. Unsure of justification of 130. On apple arm64 we're seeing this number comeout to 128.6
rdar://101436019
Differential Revision: https://reviews.llvm.org/D141170
The SigCtx function lazily allocates a ThreadSignalContext, and stores it
in the ThreadState. This function may be called by various interceptors and
the signal handler itself.
If SigCtx itself is interrupted by a signal, then (prior to this fix) there
was a possibility of allocating two ThreadSignalContexts. This not only
leaks, it fails to deliver the signal to the program's signal handler, as
the recorded signal is overwritten by the new ThreadSignalContext.
Fix this by using a CAS to swap in the ThreadSignalContext, preventing the
race. Add a test for this case.
Reviewed By: dvyukov, melver
Differential Revision: https://reviews.llvm.org/D140582
Complex scenario, but reports when there's both a use-after-free and
buffer-underflow that is in-page (i.e. doesn't touch the guard page)
ended up generating a pretty bad report:
'Use After Free at 0x7ff392e88fef (18446744073709551615 bytes into a
1-byte allocation at 0x7ff392e88ff0) by thread 3836722 here:'
(note the 2^64-bytes-into-alloc, very cool and good!)
Fix up that case, and add a diagnostic about when you have both a
use-after-free and a buffer-overflow that it's probably a bogus report
(assuming the developer didn't *really* screw up and have a uaf+overflow
bug at the same time).
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D139885
We incorrectly install the atfork handlers multiple times in the test
harness, tracked down to the default parameter used by
CheckLateInitIsOK. This manifested in a hang if running the tests with
--gtest_repeat={>=2} as the atfork handler ran multiple times, causing
double-lock and double-unlock, which on my machine hung.
Add a check-fail for this case as well to prevent this from happening
again (it was difficult to track down and is an easy mistake to make).
Differential Revision: https://reviews.llvm.org/D139731
Currently it is just an empty implementation to allow the project to link.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D141147
LFS64 symbols in musl are for glibc-ABI-compat and not intended for linking
(correct usage will not create LFS64 references). The next release 1.2.4 will
disallow linking against LFS64 symbols[1].
For sanitizers, let's just remove LFS64 interceptors. In case of erroneous LFS64
references, asan/tsan will detect fewer problems and msan may have false
positives.
[1]: https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D141186
Now that D137666 requires 48-bit VMA for AArch64, we can switch to
SizeClassAllocator64 for a slightly more efficient allocator
(asan/lsan already switched by default).
It seems that we can pick kSpaceBeg = 0xE00000000000ULL to support both Linux
("app-15") and FreeBSD ("high memory").
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140792
Currently, tsan's memory mappings include 4GB
for high app, 20GB for mid app, and 8GB for low
app. The high app and mid app mappings are
too small for large programs, especially if ASLR
entropy (mmap_rnd_bits) is set higher. The low app
region (for non-PIE) is too small for some of tcmalloc's
internal tests (this does not affect normal apps,
since tsan will replace malloc).
This CL increases the memory mappings to 4TB for
high app, 1.3TB for mid app, and 10TB for low app. Note
that tsan's 44-bit pointer compression/decompression imposes
a 16TB limit on the combined size of the app mappings, making
this set of mappings more or less maximal.
Differential Revision: https://reviews.llvm.org/D140923
