The system call now fails when it cannot write the requested size.
Update the sanitizer runtime Fuchsia implementation accordingly.
Differential Revision: https://reviews.llvm.org/D44770
llvm-svn: 328273
Summary:
- Use internal_syscall_ptr in internal_readlink
- use sigcontext on OpenBSD
Patch by David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44713
llvm-svn: 328239
Summary:
`sanitizer_common`'s coverage support is fairly well separated, and libcdep by
default. Several sanitizers don't make use of coverage, and as far as I can
tell do no benefit from the extra dependencies pulled in by the coverage public
interface functions.
The following sanitizers call `InitializeCoverage` explicitely: MSan, ASan,
LSan, HWAsan, UBSan. On top of this, any sanitizer bundling RTUBSan should
add the coverage RT as well: ASan, Scudo, UBSan, CFI (diag), TSan, MSan, HWAsan.
So in the end the following have no need: DFSan, ESan, CFI, SafeStack (nolibc
anyway), XRay, and the upcoming Scudo minimal runtime.
I tested this with all the sanitizers check-* with gcc & clang, and in
standalone on Linux & Android, and there was no issue. I couldn't test this on
Mac, Fuchsia, BSDs, & Windows for lack of an environment, so adding a bunch of
people for additional scrunity. I couldn't test HWAsan either.
Reviewers: eugenis, vitalybuka, alekseyshl, flowerhack, kubamracek, dberris, rnk, krytarowski
Reviewed By: vitalybuka, alekseyshl, flowerhack, dberris
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44701
llvm-svn: 328204
Summary:
Following-up the refactoring of mmap interceptors, adding a new common
option to detect PROT_WRITE|PROT_EXEC pages request.
Patch by David CARLIER
Reviewers: vitalybuka, vsk
Reviewed By: vitalybuka
Subscribers: krytarowski, #sanitizers
Differential Revision: https://reviews.llvm.org/D44194
llvm-svn: 328151
New API passes a callback function to the external symbolizer,
allowing it to add multiple frames to the traceback. Note that
the old interface API will be still supported until the clients
migrate to the new one.
Author: asmundak (Alexander Smundak)
Reviewed in: https://reviews.llvm.org/D44714
llvm-svn: 328079
Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Reviewers: kcc, rsmith, RKSimon, eugenis
Reviewed By: RKSimon
Subscribers: efriedma, kubamracek, dberris, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44360
llvm-svn: 327929
This is needed otherwise we'll get undefined references when trying
to use the libFuzzer built for Fuchsia.
Differential Revision: https://reviews.llvm.org/D44590
llvm-svn: 327759
Summary:
One forgotten file change + reordering one header due to clang-format
Patch by David CARLIER
Reviewers: vitalybuka, vsk
Subscribers: kubamracek, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44556
llvm-svn: 327758
Summary:
vfork is not ASan-friendly because it modifies stack shadow in the
parent process address space. While it is possible to compensate for that with, for example,
__asan_handle_no_return before each call to _exit or execve and friends, simply replacing
vfork with fork looks like by far the easiest solution.
Posix compliant programs can not detect the difference between vfork and fork.
Fixes https://github.com/google/sanitizers/issues/925
Reviewers: kcc, vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D44587
llvm-svn: 327752
Summary: Following-up the refactoring of mmap interceptors, adding a new common option to detect PROT_WRITE|PROT_EXEC pages request.
Patch by David CARLIER
Reviewers: vitalybuka, vsk
Reviewed By: vitalybuka
Subscribers: krytarowski, #sanitizers
Differential Revision: https://reviews.llvm.org/D44194
llvm-svn: 327747
This commit breaks actual Go runtime build on gomote builders (10.12) with:
xcode-select: error: tool 'xcodebuild' requires Xcode,
but active developer directory '/Library/Developer/CommandLineTools'
is a command line tools instance
Without this part build works fine.
The original commit does not include any explanation as to why
it is needed.
llvm-svn: 327700
Summary: Following-up the refactoring of mmap interceptors, adding a new common option to detect PROT_WRITE|PROT_EXEC pages request.
Patch by David CARLIER
Reviewers: vitalybuka, vsk
Reviewed By: vitalybuka
Subscribers: krytarowski, #sanitizers
Differential Revision: https://reviews.llvm.org/D44194
llvm-svn: 327696
Summary: Ripped off OpenBSD specific from the common Linux implementation
Patch by David Carlier
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: emaste, srhines, kubamracek, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44036
llvm-svn: 327674
Summary:
Without this diff, the test segfaults. Examining the generated executable
(which gets auto-deleted likely by cmake/ninja) yields this error message:
ThreadSanitizer failed to allocate 0x4000 (16384) bytes at address 1755558480000 (errno: 12)
Note that the address has more than 47 bits, which on amd64 means special
treatment and therefore points out an overflow. The allocation came from
__tsan_map_shadow on a .data pointer, which (on my work Debian-based box)
means the 0x550000000000 range. This doesn't correspond to the constants
mentioned in tsan_platform.h for Go binaries on Linux/amd64.
The diff therefore allocates memory in the sort of area Go programs would,
and prevents the test from crashing. It would be nice if reviewers kindly
considered other setups and architectures :-)
Reviewers: kcc, dvyukov
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44071
llvm-svn: 327621
Summary:
Using `getActuallyAllocatedSize` from the Combined resulting in mediocre
compiled code, as the `ClassId != 0` predicament was not propagated there,
resulting in additional branches and dead code. Move the logic in the frontend,
which results in better compiled code. Also I think it makes it slightly easier
to distinguish between the size the user requested, and the size that was
actually allocated by the allocator.
`const` a couple of things as well.
This has no functional impact.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44444
llvm-svn: 327525
Summary:
Add more standard compliant posix_memalign implementation for LSan and
use corresponding sanitizer's posix_memalign implenetations in allocation
wrappers on Mac.
Reviewers: eugenis, fjricci
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44335
llvm-svn: 327338
Summary:
The need for this change stems from the fact that Windows doesn't support
partial unmapping (`MEM_RELEASE` implies the entire allocated region). So we
now have to keep track of the reserved region and the committed region, so that
we can function without the trimming we did when dealing with larger alignments.
Instead of just having a `ReservedAddressRange` per chunk, we introduce a
`LargeChunkHeader` (and `LargeChunk` namespace) that additionally holds the
committed size and the usable size. The former is needed for stats purposes,
the latter is used by the frontend. Requiring both is debatable, we could only
work with the usable size but then be off by up to a page per chunk when
dealing with stats.
Additionally, we introduce more stats since they turned out to be useful for
experiments, and a `PrintStats` function that will be used by the combined
allocator in later patch.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D43949
llvm-svn: 327321
Summary:
This is a new version of D44261, which broke some builds with older gcc, as
they can't align on a constexpr, but rather require an integer (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859) among others.
We introduce `SANITIZER_CACHE_LINE_SIZE` in `sanitizer_platform.h` to be
used in `ALIGNED` attributes instead of using directly `kCacheLineSize`.
Reviewers: alekseyshl, thakis
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44326
llvm-svn: 327297
libFuzzer dependes on C++ library, when building for Fuchsia, we
need to ensure that libFuzzer is only being built after libc++
has been built, so we add an explicity dependency on it.
Differential Revision: https://reviews.llvm.org/D44340
llvm-svn: 327196
Summary:
Both `SizeClassInfo` structures for the 32-bit primary & `RegionInfo`
structures for the 64-bit primary can be used by different threads, and as such
they should be aligned & padded to the cacheline size to avoid false sharing.
The former was padded but the array was not aligned, the latter was not padded
but we lucked up as the size of the structure was 192 bytes, and aligned by
the properties of `mmap`.
I plan on adding a couple of fields to the `RegionInfo`, and some highly
threaded tests pointed out that without proper padding & alignment, performance
was getting a hit - and it is going away with proper padding.
This patch makes sure that we are properly padded & aligned for both. I used
a template to avoid padding if the size is already a multiple of the cacheline
size. There might be a better way to do this, I am open to suggestions.
Reviewers: alekseyshl, dvyukov
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44261
llvm-svn: 327145
This changes the add_custom_libcxx macro to resemble the
llvm_ExternalProject_Add. The primary motivation is to avoid
unnecessary libFuzzer rebuilds that are being done on every
Ninja/Make invocation. The libc++ should be only rebuilt whenever
the libc++ source itself changes.
Differential Revision: https://reviews.llvm.org/D43213
llvm-svn: 326921
Summary:
A few changes related to logging:
- prepend `Scudo` to the error messages so that users can identify that we
reported an error;
- replace a couple of `Report` calls in the RSS check code with
`dieWithMessage`/`Print`, mark a condition as `UNLIKELY` in the process;
- change some messages so that they all look more or less the same. This
includes the `CHECK` message;
- adapt a couple of tests with the new strings.
A couple of side notes: this results in a few 1-line-blocks, for which I left
brackets. There doesn't seem to be any style guide for that, I can remove them
if need be. I didn't use `SanitizerToolName` in the strings, but directly
`Scudo` because we are the only users, I could change that too.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: mgorny, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44171
llvm-svn: 326901
Disable SANITIZER_INTERCEPT_MMAP64 for SI_NETBSD.
NetBSD switched to 64-bit offsets almost 30 years ago on 32-bit platforms
and never needed mmap64() concept.
llvm-svn: 326883
I can't reproduce this build error locally, but it appears
straightforward enough to fix. r326851 renamed two of the params of this
interceptor, but apparently to update their use here.
Failure:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/4569
llvm-svn: 326876
Summary:
This change adds APIs to allow logging implementations to provide a
function for iterating through in-memory buffers (if they hold in-memory
buffers) and a way for users to generically deal with these buffers
in-process. These APIs are:
- __xray_log_set_buffer_iterator(...) and
__xray_log_remove_buffer_iterator(): installs and removes an
iterator function that takes an XRayBuffer and yields the next one.
- __xray_log_process_buffers(...): takes a function pointer that can
take a mode identifier (string) and an XRayBuffer to process this
data as they see fit.
The intent is to have the FDR mode implementation's buffers be
available through this `__xray_log_process_buffers(...)` API, so that
they can be streamed from memory instead of flushed to disk (useful for
getting the data to a network, or doing in-process analysis).
Basic mode logging will not support this mechanism as it's designed to
write the data mostly to disk.
Future implementations will may depend on this API as well, to allow for
programmatically working through the XRay buffers exposed to the
users in some fashion.
Reviewers: eizan, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43495
llvm-svn: 326866
Vitaly Buka