Summary:
The previous version of the patch makes some code unable to distinguish
failure to map address 0 and error.
Revert to turn the bots back to green while figuring out a new approach.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51451
llvm-svn: 340957
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340949
The test doesn't pass on Windows, where sizeof(long) == 4 also
on 64-bit, and so it isn't a multiple of sizeof(void*).
This also reverts the follow-up r340886.
> Summary: a constrained RingBuffer optimized for fast push
>
> Reviewers: eugenis
>
> Reviewed By: eugenis
>
> Subscribers: kubamracek, mgorny, delcypher, #sanitizers, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D51196
llvm-svn: 340924
Summary:
The UINTMAX_T type will be used in new interceptors.
While there, correct the type of strtoumax(3) from INTMAX_T to UINTMAX_T.
Original patch from Yang Zheng.
Reviewers: vitalybuka, kcc, joerg
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, tomsun.0.7, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D51106
llvm-svn: 340907
Summary:
Port libFuzzer to windows-msvc.
This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well.
It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch.
It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them.
Patch By: metzman
Reviewers: morehouse, rnk
Reviewed By: morehouse, rnk
Subscribers: morehouse, kcc, eraman
Differential Revision: https://reviews.llvm.org/D51022
llvm-svn: 340860
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
Kostya Kortchinsky