Summary:
This change removes further cases where the profiling mode
implementation relied on dynamic memory allocation. We're using
thread-local aligned (uninitialized) memory instead, which we initialize
appropriately with placement new.
Addresses llvm.org/PR38577.
Reviewers: eizan, kpw
Subscribers: jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D51278
llvm-svn: 340814
Summary:
This change saves and restores the full flags register in x86_64 mode.
This makes running instrumented signal handlers safer, and avoids flags
set during the execution of the event handlers from polluting the
instrumented call's flags state.
Reviewers: kpw, eizan, jfb
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D51277
llvm-svn: 340812
Now that all Zircon calls have been transitioned to take time as signed
value, we can transition back to ZX_TIME_INFINITE, undoing the change
made in r337802.
Differential Revision: https://reviews.llvm.org/D51266
llvm-svn: 340764
Summary:
The reason for the existence of `eraseHeader` was that it was deemed faster
to null-out a chunk header, effectively making it invalid, rather than marking
it as available, which incurred a checksum computation and a cmpxchg.
A previous use of `eraseHeader` was removed with D50655 due to a race.
Now we remove the second use of it in the Quarantine deallocation path and
replace is with a `compareExchangeHeader`.
The reason for this is that greatly helps debugging some heap bugs as the chunk
header is now valid and the chunk marked available, as opposed to the header
being invalid. Eg: we get an invalid state error, instead of an invalid header
error, which reduces the possibilities. The computational penalty is negligible.
Reviewers: alekseyshl, flowerhack, eugenis
Reviewed By: eugenis
Subscribers: delcypher, jfb, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51224
llvm-svn: 340633
- GetRandom and GetnumberOfCPUs using sys call for the former.
- enabling unit tests for the other oses.
Reviewers: kubamracek
Reviewed By: kubamracek
Differential Revision: https://reviews.llvm.org/D50937
llvm-svn: 340621
Calling task_for_pid with mach_task_self is just returning mach_task_self anyway, but it also triggers system warnings (task_for_pid is only supposed to be used by high-privileged executables). NFC.
rdar://problem/39198248
Differential Revision: https://reviews.llvm.org/D51119
llvm-svn: 340587
Summary:
`MmapNoAccess` & `MmapFixedNoAccess` return directly the result of
`internal_mmap`, as opposed to other Mmap functions that return nullptr.
This inconsistency leads to some confusion for the callers, as some check for
`~(uptr)0` (`MAP_FAILED`) for failure (while it can fail with `-ENOMEM` for
example).
Two potential solutions: change the callers, or make the functions return
`nullptr` on failure to follow the precedent set by the other functions.
The second option looked more appropriate to me.
Correct the callers that were wrongly checking for `~(uptr)0` or
`MAP_FAILED`.
TODO for follow up CLs:
- There are a couple of `internal_mmap` calls in XRay that check for
MMAP_FAILED as a result as well (cc: @dberris); they should use
`internal_iserror`;
Reviewers: eugenis, alekseyshl, dberris, kubamracek
Reviewed By: alekseyshl
Subscribers: kristina, kubamracek, delcypher, #sanitizers, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D50940
llvm-svn: 340576
On macOS Mojave, the OS started using the XOR-by-a-secret-key scheme (same as glibc is alread doing) for storing the SP value in setjmp environment. We need to adjust for that to keep supporting setjmp/longjmp on latest Darwin. The patch is basically doing the same what we're already doing for glibc.
rdar://problem/43542596
Differential Revision: https://reviews.llvm.org/D51064
llvm-svn: 340350
The synchronous dispatch functions in GCD (dispatch_sync, dispatch_barrier_sync), don't make a copy of the passed block. To maintain binary compatibility, we should avoid doing that as well in TSan, as there's no reason to do that. The synchronous dispatch functions will not return before the block is actually executed.
rdar://problem/42242579
Differential Revision: https://reviews.llvm.org/D50920
llvm-svn: 340342
Summary:
When deallocating thread stacks, we use one thread's unsafe stack size
to deallocate another thread's unsafe stack; however, the two sizes may
differ. Record an unsafe stack's size in the thread stack linked list.
Reviewers: pcc, eugenis
Reviewed By: eugenis
Subscribers: delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D51016
llvm-svn: 340308
Summary:
The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic,
but the tool interface will be general enough (or at least generalizable) to support any other libc.
When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions.
In fact, majority of interceptors become unnecessary when libc code is instrumented.
This change gets rid of most hwasan interceptors and provides interface for libc to notify
hwasan about thread creation and destruction events. Some interceptors (pthread_create)
are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in
terms of the new libc interface.
The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing
version of the library with the aforementioned pthread_create interceptor.
With the OFF setting, the library becomes more of a libc plugin.
Reviewers: vitalybuka, kcc, jfb
Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50922
llvm-svn: 340216
Summary:
Use `FUTEX_PRIVATE_FLAG` in conjunction with the wait & wake operations
employed by `BlockingMutex`. As far as I can tell, the mutexes are
process-private, and there is an actual performance benefit at employing the
private operations. There should be no downside to switching to it.
Reviewers: eugenis, alekseyshl, dvyukov
Reviewed By: dvyukov
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D50910
llvm-svn: 340178
task_vm_info is a "revisioned" structure, new OS versions add fields to the end, and compatibility is based on the reported size. On older OS versions, min_address/max_address is not filled back. Let's handle that case. Unfortunately, we can't really write a test (as the failure only happens when on a specific OS version).
Differential Revision: https://reviews.llvm.org/D50275
llvm-svn: 340058
Summary:
We avoid using dynamic memory allocated with the internal allocator in
the profile collection service used by profiling mode. We use aligned
storage for globals and in-struct storage of objects we dynamically
initialize.
We also remove the dependency on `Vector<...>` which also internally
uses the dynamic allocator in sanitizer_common (InternalAlloc) in favour
of the XRay allocator and segmented array implementation.
This change addresses llvm.org/PR38577.
Reviewers: eizan
Reviewed By: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50782
llvm-svn: 339978
Summary:
Since we're casting from double to size_t during input selection, we
really want a discrete distribution over size_t rather than a piecewise
distribution over doubles.
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50356
llvm-svn: 339973
This reapplies commit r339935 with the following changes:
* make longjmp test C, not C++, to avoid dependency on libc++/libstdc++
* untag pointer in memset interceptor
x86_64 does not have TBI, so hwasan barely works there. Tests must be carefully
written in a way that does not leak tagged pointer to system libraries.
llvm-svn: 339963
Summary:
A callback to annotate longjmp-like code.
Unlike __asan_handle_no_return, in hwasan we can not conservatively
"unpoison" the entire thread stack, because there is no such thing as
unpoisoned memory. Pointer and memory tags must always match.
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50752
llvm-svn: 339935
- The alternative syscall exists only on FreeBSD.
- Adding OpenBSD's equivalent and while at it other
remaining oses ones.
Reviewers: vitalybuka, krytarowsky, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D50760
llvm-svn: 339886
Summary:
This reverses an earlier decision to allow seg-faulting from the
XRay-allocated memory if it turns out that the system cannot provide
physical memory backing that cannot be swapped in/out on Linux.
This addresses http://llvm.org/PR38588.
Reviewers: eizan
Reviewed By: eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50831
llvm-svn: 339869
Summary:
Without this metadata LLD strips unused PC table entries
but won't strip unused guards. This metadata also seems
to influence the linker to change the ordering in the PC
guard section to match that of the PC table section.
The libFuzzer runtime library depends on the ordering
of the PC table and PC guard sections being the same. This
is not generally guaranteed, so we may need to redesign
PC tables/guards/counters in the future.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kcc, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D50483
llvm-svn: 339733
This relands commit r339405 (reverted in commit r339408.) The original
revert was due to tests failing on a darwin buildbot; however, after
looking at the affected code more I realized that the Darwin safestack
support has always been broken and disabled it in r339719. This relands
the original commit.
llvm-svn: 339723
Summary:
Darwin support does not appear to be used as evidenced by the fact that
the pthread interceptors have never worked and there is no support for
other common threading mechanisms like GCD.
Reviewers: pcc, eugenis, kubamracek
Reviewed By: pcc, kubamracek
Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D50718
llvm-svn: 339719
Summary:
There is a race window in the deallocation path when the Quarantine is bypassed.
Initially we would just erase the header of a chunk if we were not to use the
Quarantine, as opposed to using a compare-exchange primitive, to make things
faster.
It turned out to be a poor decision, as 2 threads (or more) could simultaneously
deallocate the same pointer, and if the checks were to done before the header
got erased, this would result in the pointer being added twice (or more) to
distinct thread caches, and eventually be reused.
Winning the race is not trivial but can happen with enough control over the
allocation primitives. The repro added attempts to trigger the bug, with a
moderate success rate, but it should be enough to notice if the bug ever make
its way back into the code.
Since I am changing things in this file, there are 2 smaller changes tagging
along, marking a variable `const`, and improving the Quarantine bypass test at
runtime.
Reviewers: alekseyshl, eugenis, kcc, vitalybuka
Reviewed By: eugenis, vitalybuka
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D50655
llvm-svn: 339705
compiler-rt CMake build currently tries to parse the triple and then
put it back together, but doing so inherently tricky, and doing so
from CMake is just crazy and currently doesn't handle triples that
have more than three components. Fortunatelly, the CMake really only
needs the architecture part, which is typically the first component,
to construct variants for other architectures. This means we can keep
the rest of the triple as is and avoid the parsing altogether.
Differential Revision: https://reviews.llvm.org/D50548
llvm-svn: 339701
Summary:
Export __sanitizer_malloc, etc as aliases to malloc, etc.
This way users can wrap sanitizer malloc, even in fully static binaries.
Both jemalloc and tcmalloc provide similar aliases (je_* and tc_*).
Reviewers: vitalybuka, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D50570
llvm-svn: 339614
Summary:
Don't crash when /proc/self/maps is inaccessible from main thread.
It's not a big deal, really.
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50574
llvm-svn: 339607
Summary:
Provide __hwasan_shadow_init that can be used to initialize shadow w/o touching libc.
It can be used to bootstrap an unusual case of fully-static executable with
hwasan-instrumented libc, which needs to run hwasan code before it is ready to serve
user calls like madvise().
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50581
llvm-svn: 339606
Summary:
When compiling with `WERROR=ON` & a recent clang, having the `st(?)` registers
in the clobber list produces a fatal error (except `st(7)` for some reason):
```
.../sanitizer_common/sanitizer_atomic_clang_x86.h:98:9: error: inline asm clobber list contains reserved registers: ST0, ST1, ST2, ST3, ST4, ST5, ST6 [-Werror,-Winline-asm]
"movq %1, %%mm0;" // Use mmx reg for 64-bit atomic moves
^
<inline asm>:1:1: note: instantiated into assembly here
movq 8(%esp), %mm0;movq %mm0, (%esi);emms;
^
.../sanitizer_common/sanitizer_atomic_clang_x86.h:98:9: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour.
"movq %1, %%mm0;" // Use mmx reg for 64-bit atomic moves
^
<inline asm>:1:1: note: instantiated into assembly here
movq 8(%esp), %mm0;movq %mm0, (%esi);emms;
^
```
As far as I can tell, they were in there due to the use of the `emms`
instruction, but removing the clobber doesn't appear to have a functional
impact. I am unsure if there is a better way to address this.
Reviewers: eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, delcypher, jfb, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D50562
llvm-svn: 339575
Previously the the `weak_symbols.txt` files could be modified and the
build system wouldn't update the link flags automatically. Instead the
developer had to know to reconfigure CMake manually.
This is now fixed by telling CMake that the file being used to
read weak symbols from is a configure-time dependency.
Differential Revision: https://reviews.llvm.org/D50059
llvm-svn: 339559
HWASan will not run on older Android releases where we use
__android_log_write for logging.
This dependency is also harmful in the case when libc itself depends
on hwasan, because it creates a loop of
libc -> hwasan -> liblog -> libc
which makes liblog vs libc initialization order undetermined.
Without liblog the loop is just
libc -> hwasan -> libc
and any init order issues can be solved in hwasan.
llvm-svn: 339449
This reverts commit r339405, it's failing on Darwin buildbots because
it doesn't seem to have a tgkill/thr_kill2 interface. It has a
__pthread_kill() syscall, but that relies on having a handle to the
thread's port which is not equivalent to it's tid.
llvm-svn: 339408
Summary:
glibc can call SafeStack instrumented code even after the last pthread
data destructor has run. Delay cleaning-up unsafe stacks for threads
until the thread is dead by having future threads clean-up prior threads
stacks.
Reviewers: pcc, eugenis
Reviewed By: eugenis
Subscribers: cryptoad, eugenis, kubamracek, delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D50406
llvm-svn: 339405
Summary:
When compiling with WERROR=ON, a new fatal warning started popping up recently
(due to -Werror,-Winline-asm):
```
.../lib/sanitizer_common/sanitizer_linux.cc:1214:24: error: inline asm clobber list contains reserved registers: RSP [-Werror,-Winline-asm]
"syscall\n"
^
<inline asm>:1:1: note: instantiated into assembly here
syscall
^
.../lib/sanitizer_common/sanitizer_linux.cc:1214:24: note: Reserved registers on the clobber list may not be preserved across the asm statement, and clobbering them may lead to undefined behaviour.
"syscall\n"
^
<inline asm>:1:1: note: instantiated into assembly here
syscall
^
```
Removing `rsp` from the clobber list makes the warning go away, and does not
appear to have a functional impact. If there is another way to solve this, let
me know.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D50519
llvm-svn: 339370
As for Linux with its getrandom's syscall, giving the possibility to fill buffer with native call for good quality but falling back to /dev/urandom in worst case similarly.
Reviewers: vitalybuka, krytarowski
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D48804
llvm-svn: 339318
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
llvm-svn: 339307
Dean Michael Berris