This change adds some assembler comments to facilitate analysis with
llvm-mca. In particular, we're interested in identifying and later
optimising (reducing) the cost of the key functions in the XRay
implementation using both static analysis (with llvm-mca, etc.) and
dynamic analysis (perf profiling, etc.) of microbenchmarks.
llvm-svn: 331711
Summary:
The `TestOnlyInit` function of `{Flat,TwoLevel}ByteMap` seems to be a misnomer
since the function is used outside of tests as well, namely in
`SizeClassAllocator32::Init`. Rename it to `Init` and update the callers.
Reviewers: alekseyshl, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D46408
llvm-svn: 331662
We reuse the allocation interceptors as is. RTEMS doesn't support
dlsyms. However, it needs to handle memory allocation requests before
the ASan run-time has been initialized. We use the dlsym alloc pool
for this purpose, and we increase its size to 4k to support this
usage.
Differential Revision: https://reviews.llvm.org/D46465
llvm-svn: 331649
Introduce two definitions to be used by the Myriad RTEMS port of the
ASan run-time: SANITIZER_MYRIAD2 for the platform and SANITIZER_RTEMS
for the OS. We expect to use SANITIZER_MYRIAD2 to guard the portion
of the port corresponding to Myriad's unique memory map, and
SANITIZER_RTEMS for most of the rest.
Differential Revision: https://reviews.llvm.org/D46453
llvm-svn: 331646
Summary:
This addresses http://llvm.org/PR36790.
This change allows the XRay Basic Mode implementation to use the
string-based initialization routine provided through
`__xray_log_init_mode(...)`. In the process, we've also deprecated some
flags defined for the `XRAY_OPTIONS` environment variable.
We then introduce another environment variable that can control the XRay
Basic Mode implementation through `XRAY_BASIC_OPTIONS`.
We also rename files from `xray_inmemory_log` to `xray_basic_logging` to
be more in line with the mode implementation.
Depends on D46174.
Reviewers: echristo, kpw, pelikan, eizan
Reviewed By: kpw
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46246
llvm-svn: 331507
Summary:
In this chage we add support for the string-based configuration
mechanism for configuring FDR mode.
We deprecate most of the `xray_fdr_log_*` flags that are set with the
`XRAY_OPTIONS` environment variable. Instead we make the FDR
implementation take defaults from the `XRAY_FDR_OPTIONS` environment
variable, and use the flags defined in `xray_fdr_flags.{h,cc,inc}` for
the options we support.
This change addresses http://llvm.org/PR36790.
Depends on D46173.
Reviewers: eizan, pelikan, kpw, echristo
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D46174
llvm-svn: 331506
Summary:
This addresses http://llvm.org/PR36790.
The change Deprecates a number of functions and types in
`include/xray/xray_log_interface.h` to recommend using string-based
configuration of XRay through the __xray_log_init_mode(...) function. In
particular, this deprecates the following:
- `__xray_set_log_impl(...)` -- users should instead use the
`__xray_log_register_mode(...)` and `__xray_log_select_mode(...)` APIs.
- `__xray_log_init(...)` -- users should instead use the
`__xray_log_init_mode(...)` function, which also requires using the
`__xray_log_register_mode(...)` and `__xray_log_select_mode(...)`
functionality.
- `__xray::FDRLoggingOptions` -- in following patches, we'll be
migrating the FDR logging implementations (and tests) to use the
string-based configuration. In later stages we'll remove the
`__xray::FDRLoggingOptions` type, and ask users to migrate to using the
string-based configuration mechanism instead.
- `__xray::BasicLoggingOptions` -- same as `__xray::FDRLoggingOptions`,
we'll be removing this type later and instead rely exclusively on the
string-based configuration API.
We also update the documentation to reflect the new advice and remove
some of the deprecated notes.
Reviewers: eizan, kpw, echristo, pelikan
Reviewed By: kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46173
llvm-svn: 331503
It reverts commit r331484 because it caused test failures
ThreadSanitizer-x86_64 :: Darwin/gcd-groups-destructor.mm
ThreadSanitizer-x86_64 :: Darwin/libcxx-shared-ptr-stress.mm
ThreadSanitizer-x86_64 :: Darwin/xpc-race.mm
Foundation.h transitively includes <atomic>, so we have a case of benign mixing
<stdatomic.h> and <atomic>.
llvm-svn: 331491
If the sanitizer runtime is loaded in a binary that doesn't really
support it, then __sanitizer_startup_hook will never have been
called to initialize StoredArgv. This case can't be supported, but
its failure mode shouldn't be to crash in sanitizer_common internals.
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D46344
llvm-svn: 331382
Short-circuiting causes tests to fail on Mac since libFuzzer crashes
rather than exiting with an error code when an unexpected signal
happens.
llvm-svn: 331324
Summary:
Fixes https://github.com/google/sanitizers/issues/788/, a deadlock
caused by multiple crashes happening at the same time. Before printing
a crash report, we now test and set an atomic flag. If the flag was
already set, the crash handler returns immediately.
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D46277
llvm-svn: 331310
The problem is reported in:
https://github.com/google/sanitizers/issues/945
We already disable as much as possible after multithreaded fork,
trace switching is last place that can hang due to basic
operations (memory accesses, function calls).
Disable it too.
llvm-svn: 331163
Summary:
This change is part of the larger XRay Profiling Mode effort.
Here we implement an arena allocator, for fixed sized buffers used in a
segmented array implementation. This change adds the segmented array
data structure, which relies on the allocator to provide and maintain
the storage for the segmented array.
Key features of the `Allocator` type:
* It uses cache-aligned blocks, intended to host the actual data. These
blocks are cache-line-size multiples of contiguous bytes.
* The `Allocator` has a maximum memory budget, set at construction
time. This allows us to cap the amount of data each specific
`Allocator` instance is responsible for.
* Upon destruction, the `Allocator` will clean up the storage it's
used, handing it back to the internal allocator used in
sanitizer_common.
Key features of the `Array` type:
* Each segmented array is always backed by an `Allocator`, which is
either user-provided or uses a global allocator.
* When an `Array` grows, it grows by appending a segment that's
fixed-sized. The size of each segment is computed by the number of
elements of type `T` that can fit into cache line multiples.
* An `Array` does not return memory to the `Allocator`, but it can keep
track of the current number of "live" objects it stores.
* When an `Array` is destroyed, it will not return memory to the
`Allocator`. Users should clean up the `Allocator` independently of
the `Array`.
* The `Array` type keeps a freelist of the chunks it's used before, so
that trimming and growing will re-use previously allocated chunks.
These basic data structures are used by the XRay Profiling Mode
implementation to implement efficient and cache-aware storage for data
that's typically read-and-write heavy for tracking latency information.
We're relying on the cache line characteristics of the architecture to
provide us good data isolation and cache friendliness, when we're
performing operations like searching for elements and/or updating data
hosted in these cache lines.
Reviewers: echristo, pelikan, kpw
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D45756
llvm-svn: 331141
1. Allow to suppress by current stack.
We generally allow to suppress by all main stacks.
Current is probably the stack one wants to use to
suppress such reports.
2. Fix last lock stack restoration.
We trimmed shadow value by storing it in u32.
This magically worked for the test that provoked
the report on the main thread. But this breaks
for locks in any other threads.
llvm-svn: 331023
The source being compiled is plain C, but using .cc extension forces it
to be compiled as C++ which requires a working C++ compiler including
C++ library which may not be the case when we're building compiler-rt
together with libcxx as part of runtimes build.
Differential Revision: https://reviews.llvm.org/D46152
llvm-svn: 331003
Otherwise LLD will not align the .ASAN$GA section start, and
&__asan_globals + 1 will not be the start of the next real ASan global
metadata in .ASAN$GL.
We discovered this issue when attempting to use LLD on Windows in
Chromium: https://crbug.com/837090
llvm-svn: 330990
Clang-cl supports the -gline-tables-only flag, so we were going down
that path. Honestly, we should just go ahead and enable full codeview
support.
llvm-svn: 330989
Follow up to r330840 and r330849.
It seems that s390 is also not distinguishing illegal WRITE and READ memory
access.
Add s390x to XFAIL for the tests.
llvm-svn: 330863
Summary:
This adds `__scudo_print_stats` as an interface function to display the Primary
and Secondary allocator statistics for Scudo.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D46016
llvm-svn: 330857
The read/write flag is set by manually decoding the instruction that caused
the exception. It is implemented this way because the cause register which
contains the needed flag was removed from the signal context structure which
the user handler receives from the kernel.
Patch by Milos Stojanovic.
Differential Revision: https://reviews.llvm.org/D45768
llvm-svn: 330840
This code is ill-formed, but under -fno-exceptions compilers generally accept it (at least, prior to C++17). This allows this code to be built by Clang in C++17 mode.
llvm-svn: 330765
Summary:
The following functions are only used in tests: `SetEnv`,
`SanitizerSetThreadName`, `SanitizerGetThreadName`. I don't think they are
going to be used in the future, and I propose to get rid of them, and associated
tests and include.
Reviewers: alekseyshl, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: dvyukov, vitalybuka, kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45838
llvm-svn: 330724
It doesn't make sense to non-deterministically choose between
`CopyPart(..)` and `InsertPart(..)` when it is known that
`InsertPart(..)` will fail.
This upstream's a change from JFS solver's fork of LibFuzzer.
Differential Revision: https://reviews.llvm.org/D45693
llvm-svn: 330687
A small but substantial minority of libFuzzer-based fuzzers run code that
does not play well with fork in global constructors or LLVMFuzzerInitialize.
This patch allows these fuzzers to use afl_driver by allowing them to
opt-out of using AFL's deferred forkserver which deferres calling fork until
after this code.
Patch By: metzman
Differential Revision: https://reviews.llvm.org/D45744
llvm-svn: 330652
Summary:
Example:
Printf("%-5s", "123");
should yield:
'123 '
In case Printf's requested string field width is larger than the string
argument length, the resulting string should be padded up to the requested
width.
For the simplicity sake, implementing left-justified (right padding) only.
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45906
llvm-svn: 330643
Retire the fixed shadow memory mapping to avoid conflicts with default
process memory mapping (currently manifests on Android).
Tests on AArch64 show <1% performance loss and code size increase,
making it possible to use dynamic shadow memory by default.
Keep the fixed shadow memory mapping around to be able to run
performance comparison tests later.
Re-commiting D45847 with fixed shadow for x86-64.
llvm-svn: 330624
This commit causes internal errors with ld.bfd 2.24. My guess is that
the ifunc usage in this commit is causing problems. This is the default
system linker on Trusty Tahr, which is from 2014. I claim it's still in
our support window. Maybe we will decide to drop support for it, but
let's get the bots green while we do the investigation and have that
discussion.
Discovered here: https://crbug.com/835864
llvm-svn: 330619
The profile library was missing some includes and was erroneously using
ftruncate. WinASan was using `= {0}` to initialize structs, which
creates -Wmissing-field-initializers and -Wmissing-braces warnings with
clang. Use `= {}` instead, since this is C++.
llvm-svn: 330616
Summary:
Fuchsia uses zx_system_get_features in lieu of getauxval.
Use this call when checking for CRC32 support.
Reviewers: cryptoad
Reviewed By: cryptoad
Subscribers: delcypher, llvm-commits, #sanitizers, kristof.beyls, chrib
Differential Revision: https://reviews.llvm.org/D45896
llvm-svn: 330598
Summary:
Retire the fixed shadow memory mapping to avoid conflicts with default
process memory mapping (currently manifests on Android).
Tests on AArch64 show <1% performance loss and code size increase,
making it possible to use dynamic shadow memory by default.
For the simplicity and unifirmity sake, use dynamic shadow memory mapping
with base address accessed via ifunc resolver on all supported platforms.
Keep the fixed shadow memory mapping around to be able to run
performance comparison tests later.
Complementing D45840.
Reviewers: eugenis
Subscribers: srhines, kubamracek, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45847
llvm-svn: 330474
Although sprintf is not intercepted on Windows, this test can pass
if sprintf calls memmove, which is intercepted, so we can't XFAIL it.
Differential Revision: https://reviews.llvm.org/D45894
llvm-svn: 330469
Summary:
Example:
Printf("%.*s", 5, "123");
should yield:
'123 '
In case Printf's requested string precision is larger than the string
argument, the resulting string should be padded up to the requested
precision.
For the simplicity sake, implementing right padding only.
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45844
llvm-svn: 330458
This test is failing on my Linux box. Just increasing the number of
iterations works around this. The divergence is likely due to
our reliance on `std::shuffle()` which is not guaranteed to have
the same behaviour across platforms.
This is a strong argument for us to implement our own shuffle
function to avoid divergence in behaviour across platforms.
Differential Revision: https://reviews.llvm.org/D45767
llvm-svn: 330390
Summary:
Some of the functions had spurious conditional statements and checks, and some
intermediary variables that I feel made the code more complicated than it needs
to be. Also, when unmapping the whole range, the range size would be 0, but
the base was set to the address of the end of the range, which sounds prone to
error. I think nulling out the base in this scenario is a better way to go.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45775
llvm-svn: 330355
The initial naive approach to simulate SIGINT on Fuchsia was to getchar
and look for ETX. This caused the InterruptHandler thread to lock stdin,
preventing musl's exit() from being able to close the stdio descriptors
and complete. This change uses select() instead.
Patch By: aarongreen
Differential Revision: https://reviews.llvm.org/D45636
llvm-svn: 330328
Summary:
"N" suffix is added by the instrumentation and interface functions
are expected to be exported from the library as __hwasan_loadN* and
__hwasan_storeN*.
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45739
llvm-svn: 330297
Summary:
While I was sifting through dead code findings, I stumbled on this function.
First, for `__s390__` it always returned 0 for the 1st call, which doesn't seem
right. 2nd call & beyond would return the correct value though.
Then it duplicated the `atomic_store` multiple times, sometimes with a `if`,
sometimes without. Finally it used a capitalized variable name starting with `k`
which indicates a constant, and it is not.
So:
- rename the static global variable;
- change the atomic functions to their relaxed version;
- move the store to the end, and make sure we return `val` all the time.
Reviewers: alekseyshl, eugenis, koriakin
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45725
llvm-svn: 330268
Summary:
Typed event patching is implemented for x86-64, but functions must
be defined for other arches.
Reviewers: dberris, pelikan
Subscribers: nemanjai, javed.absar, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45749
llvm-svn: 330231
Summary:
Compiler-rt support first before defining the __xray_typedevent() lowering in
llvm. I'm looking for some early feedback before I touch much more code.
Reviewers: dberris
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43668
llvm-svn: 330218
Summary:
Going through the dead code findings, the code removed in this CL appears to be
pretty straightforward to remove, and seems to be some leftover from previous
refactors.
Reviewers: alekseyshl, eugenis
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45704
llvm-svn: 330190
Summary:
It looks like OSX's UBSan needs a "NoHooks" version of
`RTSanitizerCommonSymbolizer` to work build properly.
Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45696
llvm-svn: 330146
Summary:
Host symbolizer & stacktraces related code in their own RT:
`RTSanitizerCommonSymbolizer`, which is "libcdep" by nature. Symbolizer &
stacktraces specific code that used to live in common files is moved to a new
file `sanitizer_symbolizer_report.cc` as is.
The purpose of this is the enforce a separation between code that relies on
symbolization and code that doesn't. This saves the inclusion of spurious code
due to the interface functions with default visibility, and the extra data
associated.
The following sanitizers makefiles were modified & tested locally:
- dfsan: doesn't require the new symbolizer RT
- esan: requires it
- hwasan: requires it
- lsan: requires it
- msan: requires it
- safestack: doesn't require it
- xray: doesn't require it
- tsan: requires it
- ubsan: requires it
- ubsan_minimal: doesn't require it
- scudo: requires it (but not for Fuchsia that has a minimal runtime)
This was tested locally on Linux, Android, Fuchsia.
Reviewers: alekseyshl, eugenis, dberris, kubamracek, vitalybuka, dvyukov, mcgrathr
Reviewed By: alekseyshl, vitalybuka
Subscribers: srhines, kubamracek, mgorny, krytarowski, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45457
llvm-svn: 330131
The current implementation of the Go sanitizer only works on x86_64.
Added some modifications to the buildgo.sh script and the Tsan code
to make it work on powerpc64/linux.
Author: cseo (Carlos Eduardo Seo)
Reviewed in: https://reviews.llvm.org/D43025
llvm-svn: 330122
When bulding libFuzzer as part of the toolchain, C++ library may not
have been fully built yet so the C++ compiler checks will fail, but we
don't care since we don't need C++ library anyway as we're building
our own.
Differential Revision: https://reviews.llvm.org/D45638
llvm-svn: 330075
Summary:
In the same spirit of SanitizerToolName, allow the Primary & Secondary
allocators to have names that can be set by the tools via PrimaryAllocatorName
and SecondaryAllocatorName.
Additionally, set a non-default name for Scudo.
Reviewers: alekseyshl, vitalybuka
Reviewed By: alekseyshl, vitalybuka
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45600
llvm-svn: 330055
Summary:
- last change (+ the Apple support change) missed a lot of indentation
- shorten architecture SOURCES definitions as most fit 1 line/arch
- comment in English what's where, and where the different .a come from
(using only the word "runtime" in the comment isn't useful, since the
CMake primitive itself says "runtime" in its name)
- skip unsupported architectures quickly, to avoid extra indentation
Reviewers: dberris, eizan, kpw
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45568
llvm-svn: 329998
Objective-C's @synchronize synchronization primitive uses calls to objc_sync_enter and objc_sync_exit runtime functions. In most cases, they end up just calling pthread_mutex_lock/pthread_mutex_unlock, but there are some cases where the synchronization from pthread_mutex_lock/pthread_mutex_unlock interceptors isn't enough. Let's add explicit interceptors for objc_sync_enter and objc_sync_exit to handle all cases.
Differential Revision: https://reviews.llvm.org/D45487
llvm-svn: 329982
IsStackOverflow only treats accesses within 512 bytes of SP as stack-overflow. This should really be the size of a page instead.
The scariness_score_test.cc triggers stack overflow with frames that are even larger than a page, which can also trigger a fault that will not be recognized as stack-overflow. Let's just use smaller frames.
llvm-svn: 329980
Summary:
Now that common options are propagated again for runtimes build with D45507,
the -f{data,function}-sections flags are now duplicates, remove them.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45575
llvm-svn: 329925
Summary:
This was missed during the review of D38595, but the vmo name size computation
should use internal_strlen, not sizeof, otherwise we end up with 7 character
names.
Reviewers: mcgrathr, flowerhack
Reviewed By: mcgrathr
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45525
llvm-svn: 329842
The Android sanitizer buildbot is failing with this change and it
looks like an additional change to cmake is necessary to fix the
build. Reverting this change for now.
llvm-svn: 329828
CMAKE_CXX_FLAGS was added twice to the command line. This causes the command
line options to be doubled which works until it doesn't as not all options
can be specified twice.
For example,
clang-cl foo.c /GS- /GS- -mllvm -small-loop-cost=1 -mllvm -small-loop-cost=1
clang (LLVM option parsing): for the -small-loop-cost option: may only occur zero or one times!
llvm-svn: 329817
Summary:
This patch implements the `-fxray-modes=` flag which allows users
building with XRay instrumentation to decide which modes to pre-package
into the binary being linked. The default is the status quo, which will
link all the available modes.
For this to work we're also breaking apart the mode implementations
(xray-fdr and xray-basic) from the main xray runtime. This gives more
granular control of which modes are pre-packaged, and picked from
clang's invocation.
This fixes llvm.org/PR37066.
Note that in the future, we may change the default for clang to only
contain the profiling implementation under development in D44620, when
that implementation is ready.
Reviewers: echristo, eizan, chandlerc
Reviewed By: echristo
Subscribers: mgorny, mgrang, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D45474
llvm-svn: 329772
Summary:
This is a redo of D45296.
It looks like the random stack-protector issues I was getting were coming from
my Android emulator, and updating everything all around and relaunching stuff
ended up making it go away.
I guess I'll have to see how it behaves on the bots.
Only additional change from the previous CL is some `const` were appropriate.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45461
llvm-svn: 329706
Disabling threads makes <atomic> unusable, but this is needed by LLVM
libraries that are dependencies of the symbolizer.
Differential Revision: https://reviews.llvm.org/D45424
llvm-svn: 329672
Summary:
- getentropy presence since late 2014, safe to use.
- guarantees to delivers good random data up to 256 bytes.
- fall back to /dev/urandom as long the buffer is correct.
Patch by David CARLIER
Reviewers: kubamracek, vitalybuka
Reviewed By: vitalybuka
Subscribers: cryptoad, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44866
llvm-svn: 329633
Summary:
- Enabling libfuzzer on OpenBSD
- OpenBSD can t support asan, msan ... the tests can t be run.
Patch by David CARLIER
Reviewers: eugenis, phosek, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44877
llvm-svn: 329631
Summary:
Even this version seems to mess with Android somehow. Reverting for now while
I figure out what's up.
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45450
llvm-svn: 329606
Summary:
Still pursuing the ultimate goal of splitting the Symbolizer code from
RTSanitizerCommon core, allow `BackgroundThread` to work even when not linked
with `sanitizer_stackdepot.cc`. There is no reason this function should pull in
the whole `StackDepot` if symbolization is not supported.
Currently this has no functional change as the depot is always linked anyway.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45296
llvm-svn: 329595
Summary:
Minor style changes to complement D44404:
- make use of a new ErrorBase ctor
- de-duplicate a comment about VS2013 support
Reviewers: eugenis
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D45390
llvm-svn: 329586
opened.
Summary:
Currently if the directory cannot be opened for a reason other than
non-existence (e.g. too many open file descriptors) the error message
printed is incredibly confusing.
Patch By: Alex Gaynor
Reviewers: kcc, morehouse
Reviewed By: morehouse
Subscribers: delcypher, llvm-commits, Sanitizers
Differential Revision: https://reviews.llvm.org/D45322
llvm-svn: 329438
Summary:
Under some circumstances (that I haven't dug further into), the first stack
frame for the test looks like:
`#0 0x4e6038 in __interceptor_memalign.localalias.1 ...compiler-rt/lib/asan/asan_malloc_linux.cc:113`
which isn't matched by the current CHECK.
Expand the CHECK to match aligned_alloc or memalign. Hopefully this should fix
the PowerPC issue as well, otherwise we'll bring back the FIXME.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D45281
llvm-svn: 329226
Summary:
ShadowCallStack does not yet have a runtime provided by compiler-rt, but
this change includes simple tests that make use of a very minimal
runtime in test/shadowcallstack/minimal_runtime.h
Reviewers: pcc, kcc, delcypher, eugenis, filcab
Reviewed By: pcc
Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D44803
llvm-svn: 329210
This expands the CMake check to handle both statically and dynamically
linked version of libc++abi and libunwind and matches the implemnetation
used elsewhere in LLVM.
Differential Revision: https://reviews.llvm.org/D45242
llvm-svn: 329205
Summary:
The purpose of this set of changes is to separate stackframe/symbolizer support into their own RT within sanitizer_common.
Sanitizers with no use for those could then be built without the extraneous dependencies pulled in by the default visibility interface functions.
I am aiming to do small changes for specific platforms.
In this one, we split the unwind functions from sanitizer_win.cc into their own sanitizer_unwind_win.cc.
Reviewers: alekseyshl, rnk
Reviewed By: alekseyshl, rnk
Subscribers: delcypher, #sanitizers, kubamracek, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D44799
llvm-svn: 329204
Summary:
This is D45125; the patch enables the build of XRay on OpenBSD. We also
introduce some OpenBSD specific changes to the runtime implementation,
involving how we get the TSC rate through the syscall interface specific
to OpenBSD.
Reviewers: dberris
Authored by: devnexen
Subscribers: dberris, mgorny, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D45125
llvm-svn: 329189
Summary:
`Symbolizer::PrepareForSandboxing` is empty for all platforms and apparently
has been for a while (D10213). Remove it, and shuffle things around so that the
platform specific code is now in `PlatformPrepareForSandboxing`.
This allows to have one less symbolizer dependency in a common file, which
helps for the upcoming split.
Also remove `SymbolizerPrepareForSandboxing` in tsan_go which appears to not
be used anywhere.
Reviewers: alekseyshl, eugenis, dvyukov, mcgrathr
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44953
llvm-svn: 329094
This patch fixes the following issues:
(1) The strong definition of the merge hook function was not working which
breaks the online value profile merging. This patch removes the weak
attribute of VPMergeHook and assigns the value dynamically.
(2) Truncate the proifle file so that we don't have garbage data at the end of
the file.
(3) Add new __llvm_profile_instrument_target_value() interface to do the value
profile update in batch. This is needed as the original incremental by 1
in __llvm_profile_instrument_target() is too slow for online merge.
Differential Revision: https://reviews.llvm.org/D44847
llvm-svn: 328987
As many other ASan tests already, has to disable these failing tests on
arm, armhf and aarch64 configs.
Differential Revision: https://reviews.llvm.org/D44404
llvm-svn: 328849
and the general version to avoid use of libstdc++ on non-Linux
platforms.
This is motivated by the fact that using `libstdc++` is deprecated on
Darwin and maybe removed some day.
Differential Revision: https://reviews.llvm.org/D44733
llvm-svn: 328775
This check "CHECK: {{#0 0x.* in .*aligned_alloc}}" fails on ppc64be, gcc
build. Disabling the test for gcc for now.
Differential Revision: https://reviews.llvm.org/D44404
llvm-svn: 328741
Summary:
Currently many allocator specific errors (OOM, for example) are reported as
a text message and CHECK(0) termination, not stack, no details, not too
helpful nor informative. To improve the situation, ASan detailed errors were
defined and reported under the appropriate conditions.
Issue: https://github.com/google/sanitizers/issues/887
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44404
llvm-svn: 328722
To minimize testing surface (remove libstdc++ from the picture, for
one), make use-after-free c, not c++ test.
Differential Revision: https://reviews.llvm.org/D44705
llvm-svn: 328646
For a few tests, volatile was placed before the '*' in pointer
declarations, resulting in it applying to the underlying data rather
than the pointer itself. Placing volatile after the '*' allows us to
switch those tests to -O2.
llvm-svn: 328633
Summary:
Fuchsia requires its Scudo shared runtime to not be C++ dependant. Since they
don't use UBSan in conjunction with Scudo, we can just remove the runtime,
and add the extra `nostdinc++` and `nostdlib++` flags. No need for Coverage
either. This allows to keep things going while working on additional splits
of sanitizer_commong and a more minimal runtime.
Reviewers: phosek, flowerhack, alekseyshl
Reviewed By: phosek, alekseyshl
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44791
llvm-svn: 328625
Summary:
Porting HWASan to Linux x86-64, first of the three patches, compiler-rt part.
The approach is similar to ARM case, trap signal is used to communicate
memory tag check failure. int3 instruction is used to generate a signal,
access parameters are stored in nop [eax + offset] instruction immediately
following the int3 one
Had to add HWASan init on malloc because, due to much less interceptors
defined (most other sanitizers intercept much more and get initalized
via one of those interceptors or don't care about malloc), HWASan was not
initialized yet when libstdc++ was trying to allocate memory for its own
fixed-size heap, which led to CHECK-fail in AllocateFromLocalPool.
Also added the CHECK() failure handler with more detailed message and
stack reporting.
Reviewers: eugenis
Subscribers: kubamracek, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D44705
llvm-svn: 328385
Summary:
Disables certain CMP optimizations to improve fuzzing signal under -O1
and -O2.
Switches all fuzzer tests to -O2 except for a few leak tests where the
leak is optimized out under -O2.
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D44798
llvm-svn: 328384
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
Summary:
For some reason CMake can't find the `append` macro if LLVM is built separately and imported via `LLVM_CONFIG_PATH`.
Patch by Loo Rong Jie
Reviewers: rnk, vitalybuka
Reviewed By: rnk, vitalybuka
Subscribers: dberris, mgorny, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43458
llvm-svn: 327876
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
by explicitly listing where we expect this test to work.
Because this test invokes undefined behaviour all sorts of things
can happen (e.g. crash, or on some bots asan manages to catch
something). The test seems to pass okay on Darwin (x86_64/x86_64/i386)
and on Linux (x86_64/i386) so explicitly require one of these platforms
to run the test.
llvm-svn: 327185
The retpoline mitigation for variant 2 of CVE-2017-5715 inhibits the
branch predictor, and as a result it can lead to a measurable loss of
performance. We can reduce the performance impact of retpolined virtual
calls by replacing them with a special construct known as a branch
funnel, which is an instruction sequence that implements virtual calls
to a set of known targets using a binary tree of direct branches. This
allows the processor to speculately execute valid implementations of the
virtual function without allowing for speculative execution of of calls
to arbitrary addresses.
This patch extends the whole-program devirtualization pass to replace
certain virtual calls with calls to branch funnels, which are
represented using a new llvm.icall.jumptable intrinsic. It also extends
the LowerTypeTests pass to recognize the new intrinsic, generate code
for the branch funnels (x86_64 only for now) and lay out virtual tables
as required for each branch funnel.
The implementation supports full LTO as well as ThinLTO, and extends the
ThinLTO summary format used for whole-program devirtualization to
support branch funnels.
For more details see RFC:
http://lists.llvm.org/pipermail/llvm-dev/2018-January/120672.html
Differential Revision: https://reviews.llvm.org/D42453
llvm-svn: 327163
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 fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection. See the included testcase for an example.
Differential Revision: https://reviews.llvm.org/D43959
llvm-svn: 327062
This fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection.
Differential Revision: https://reviews.llvm.org/D43959
llvm-svn: 327031
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
Darwin needs xlocale.h but I see no precedence in the code how non-Posix
headers like this are handled and I am not experienced with this code. Just
disable the tests for now to recover the bots.
rdar://38208146
llvm-svn: 326874
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
Summary:
This change makes changes to XRay implementation files trigger re-builds
of the unit tests. Prior to this change, the unit tests were not built
and run properly if the implementation files were changed during the
development process. This change forces the dependency on all files in
the XRay include and lib hosted files in compiler-rt.
Caveat is, that new files added to the director(ies) will need a re-run
of CMake to re-generate the fileset.
We think this is an OK compromise, since adding new files may
necessitate editing (or adding) new unit tests. It's also less likely
that we're adding new files without updating the CMake configuration to
include the functionality in the XRay runtime implementation anyway.
Reviewers: pelikan, kpw, nglevin
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D44080
llvm-svn: 326842
Summary:
If not using `-Wl,--gc-sections`, a whole lot of unused `sanitizer_common` code
and related static variables are pulled into the shared library.
Keep the binary size smaller, and its memory footprint smaller as well, by
using the compiler flags `-ffunction-section` & `-fdata-sections` by default,
as well as the linker flags `-Wl,--gc-sections`.
Current experiments show a large discrepency between binary sizes generated
by gcc (big) and clang (small). I am not sure yet how I can make a test that
would encompass both, so it's an outstanding work item.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: mgorny, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44121
llvm-svn: 326833
Summary: define RLIMIT_AS constant until it s defined in the future
Patch by: David Carlier
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44068
llvm-svn: 326768
This is triggering "functions that differ only in their return type
cannot be overloaded" error.
Differential Revision: https://reviews.llvm.org/D44126
llvm-svn: 326759
These operations are now obsolete on NetBSD and will be removed.
No functional change for other OSes.
Sponsored by <The NetBSD Foundation>
llvm-svn: 326663
PT_SET_SIGMASK and PT_GET_SIGMASK will be removed from NetBSD
without backward compat (it shortlived in a development branch).
Sponsored by <The NetBSD Foundation>
llvm-svn: 326657
Summary:
Extract INIT_PTHREAD_ATTR_GET_SCHED from INIT_PTHREAD_ATTR_GET,
as the former is not supported on OpenBSD.
Supported interceptors
getdetachstate, getguardsize, getscope, getstacksize, getgrouplist and getstack
Unsupported
getschedparam, getgroupmembership and getschedpolicy
Patch by David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: fedor.sergeev, srhines, kubamracek, mgorny, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44035
llvm-svn: 326653
Summary: Moving from ptr to u64 for GetTid posix implementation.
[FreeBSD] Moving from pthread_self to thr_self more appropriate to get thread ID.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43998
llvm-svn: 326647
Summary:
On OpenBSD no multi arch support
Enabling only UBsan and disabling Asan.
Patch by: David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44017
llvm-svn: 326646
Summary:
Enabling the memory sanitizer support for FreeBSD, most of unit tests are compatible.
- Adding fstat and stressor_r interceptors.
- Updating the struct link_map access since most likely the struct Obj_Entry had been updated since.
- Disabling few unit tests until further work is needed (or we can assume it can work in real world code).
Patch by: David CARLIER
Reviewers: vitalybuka, krytarowski
Reviewed By: vitalybuka
Subscribers: eugenis, dim, srhines, emaste, kubamracek, mgorny, fedor.sergeev, hintonda, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43080
llvm-svn: 326644
Programs without any code in them should export the exact same set of
symbols as programs with code, at least on Darwin. This is done to make
text-based API verification possible for certain Darwin frameworks.
llvm-svn: 326351
Summary:
For RISCV32, we must force enable int128 for compiling long double routines using the flag -fforce-enable-int128.
Related clang patch: https://reviews.llvm.org/D43105
Reviewers: asb, kito-cheng, apazos, compnerd, howard.hinnant
Reviewed By: kito-cheng
Subscribers: shiva0217, efriedma, mgorny, hintonda, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43106
llvm-svn: 326346
This is a workarond for the fallout from D42644:
[asan] Intercept std::rethrow_exception indirectly.
Reported problem on NetBSD/amd64:
$ sh ./projects/compiler-rt/test/sanitizer_common/asan-i386-NetBSD/NetBSD/Output/ttyent.cc.script
/usr/lib/i386/libgcc.a(unwind-dw2.o): In function `_Unwind_RaiseException':
unwind-dw2.c:(.text+0x1b41): multiple definition of `_Unwind_RaiseException'
/public/llvm-build/lib/clang/7.0.0/lib/netbsd/libclang_rt.asan-i386.a(asan_interceptors.cc.o):/public/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:337: first defined here
clang-7.0: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-svn: 326216
Summary:
Instead of using `AlignedChunkHeaderSize`, introduce a `constexpr` function
`getHeaderSize` in the `Chunk` namespace. Switch `RoundUpTo` to a `constexpr`
as well (so we can use it in `constexpr` declarations). Mark a few variables
in the areas touched as `const`.
Overall this has no functional change, and is mostly to make things a bit more
consistent.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D43772
llvm-svn: 326206
Update min deployment target in some tests so that they don't try
to link against libarclite and don't fail when it's not available.
rdar://problem/29253617
Reviewers: vsk, kubamracek
Reviewed By: vsk
Subscribers: jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43787
llvm-svn: 326143
Summary:
Fixes Bug 32434
See https://bugs.llvm.org/show_bug.cgi?id=32434
Short summary:
std::rethrow_exception does not use __cxa_throw to rethrow the exception, so if
it is called from uninstrumented code, it will leave the stack poisoned. This
can lead to false positives.
Long description:
For functions which don't return normally (e.g. via exceptions), asan needs to
unpoison the entire stack. It is not known before a call to such a function
where execution will continue, some function which don't contain cleanup code
like destructors might be skipped. After stack unwinding, execution might
continue in uninstrumented code.
If the stack has been poisoned before such a function is called, but the stack
is unwound during the unconventional return, then zombie redzones (entries) for
no longer existing stack variables can remain in the shadow memory. Normally,
this is avoided by asan generating a call to asan_handle_no_return before all
functions marked as [[noreturn]]. This asan_handle_no_return unpoisons the
entire stack. Since these [[noreturn]] functions can be called from
uninstrumented code, asan also introduces interceptor functions which call
asan_handle_no_return before running the original [[noreturn]] function;
for example, cxa_throw is intercepted.
If a [[noreturn]] function is called from uninstrumented code (so the stack is
left poisoned) and additionally, execution continues in uninstrumented code, new
stack variables might be introduced and overlap with the stack variables
which have been removed during stack unwinding. Since the redzones are not
cleared nor overwritten by uninstrumented code, they remain but now contain
invalid data.
Now, if the redzones are checked against the new stack variables, false
positive reports can occur. This can happen for example by the uninstrumented
code calling an intercepted function such as memcpy, or an instrumented
function.
Intercepting std::rethrow_exception directly is not easily possible since it
depends on the C++ standard library implementation (e.g. libcxx vs libstdc++)
and the mangled name it produces for this function. As a rather simple
workaround, we're intercepting _Unwind_RaiseException for libstdc++. For
libcxxabi, we can intercept the ABI function __cxa_rethrow_primary_exception.
Patch by Robert Schneider.
Reviewers: kcc, eugenis, alekseyshl, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42644
llvm-svn: 326132
FindAvailableMemoryRange can currently overwrite existing memory (by restricting the VM below addresses that are already used). This patch adds a check to make sure we don't restrict the VM space too much. We are also now more explicit about why the lookup failed and print out verbose values.
Differential Revision: https://reviews.llvm.org/D43318
llvm-svn: 326106
Summary:
Print current stack on CHECK violation to aid debugging and
match other sanitizers functionality.
Reviewers: eugenis
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43692
llvm-svn: 326105
Summary:
Start making the Scudo tests less Linux-y:
- `malloc_usable_size` doesn't exist everywhere, so replace them with
`__sanitizer_get_allocated_size` which we provide;
- move all the `memalign` related tests into `memalign.c` since it's also not
available everywhere.
I also noticed that the `memalign.c` was missing a line in one of the loops.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D43393
llvm-svn: 326100
`ubsan_minimal` makes use of the `_sanitizer::atomic_load` function.
This function uses the `DCHECK` macro which in debug builds will use
the `_sanitizer::CheckFailed` function.
This function is part of `sanitizer_common` but `ubsan_minimal` doesn't
use this so the implementation is missing which leads to link failures
on macOS when trying to link `libclang_rt.ubsan_minimal_osx_dynamic.dylib`.
This is in contrast to the BFD linker on Linux which doesn't seem to care
about the missing symbol.
A basic implementation of `_sanitizer::CheckFailed` has been added to
the `ubsan_minimal` debug build to avoid the link error. The
implementation could definitely be improved but I don't know which
functions can be used in this context so I decided to restrict myself to
functions only being used in `ubsan_minimal` already.
llvm-svn: 326032
Summary:
Interceptors initialization may need to allocate memory. So if we initialize too
early we can crash in non initialized allocator.
Reviewers: pcc, eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43669
llvm-svn: 326025
Summary:
The setlocale(3) function reloads the ctype(3) arrays from
external files. This happens behind the scenes in the internals
of libc (citrus library, runes functions etc).
ctype(3) functions like isspace(3) can be provided with two
variations on NetBSD: inlined or via a global symbol in libc:
```
#if defined(_NETBSD_SOURCE) && !defined(_CTYPE_NOINLINE) && \
!defined(__cplusplus)
#include <sys/ctype_inline.h>
#else
#include <sys/ctype_bits.h>
#endif
```
The in-lined versions are de-facto array lookup operations.
```
#define isspace(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_S))
```
After setting setlocale(3) the ctype(3) arrays (_ctype_tab_,
_toupper_tab_, _tolower_tab_) are reload behind the scenes
and they are required to be marked as initialized.
Set them initialized inside the common setlocale(3) interceptor.
The arrays are of size of 257 elements: 0..255 + 1 (EOF).
This corrects errors on NetBSD/amd64 in applications
prebuilt with MSan.
Sponsored by <The NetBSD Foundation>
Reviewers: vitalybuka, dvyukov, joerg
Reviewed By: vitalybuka
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D42020
llvm-svn: 326008
Summary:
There are applications out there which allocate more than 1 << 18 large chunks
of memory (those handled by LargeMmapAllocator, aka secondary allocator).
For 64 bits, secondary allocator stores allocated chunks in a growing on
demand region of memory, growing in blocks of 128K, up to 1 << 20 chunks total.
Sanitizer internal allocator's secondary uses fixed size array storing up
to 1 << 15 chunks (down to 256K from 2Mb of memory used for that array).
Nothing is changed for 32 bits, chunks are still stored in the fixed size
array (up to 1 << 15 chunks).
Reviewers: eugenis
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D43693
llvm-svn: 326007
Reported on a buildbot:
Error in XFAIL list:
couldn't parse text: '| arm || aarch64 || mips'
in expression: 'freebsd | arm || aarch64 || mips'
Add || in the place of |
Fallout from D43382
llvm-svn: 325751
Summary:
The Unix subdirectory mostly allows only on Linux x86_64 but now we can target x86_64 arch in general.
Patch by David CARLIER
Reviewers: krytarowski, dberris, emaste
Reviewed By: krytarowski, dberris, emaste
Subscribers: emaste, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43382
llvm-svn: 325743
This patch changes hwasan inline instrumentation:
Fixes address untagging for shadow address calculation (use 0xFF instead of 0x00 for the top byte).
Emits brk instruction instead of hlt for the kernel and user space.
Use 0x900 instead of 0x100 for brk immediate (0x100 - 0x800 are unavailable in the kernel).
Fixes and adds appropriate tests.
Patch by Andrey Konovalov.
Differential Revision: https://reviews.llvm.org/D43135
llvm-svn: 325711
Summary:
Child thread may finish before pthread_setname_np() and/or
pthread_getname_np() had a chance to run, which causes these functions
to fail with ENOENT (meaning /proc/self/task/[tid]/comm doesn't exist).
Fix by stalling child thread on a mutex.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43548
llvm-svn: 325703
Summary: No supported oses normally compiled that code (or not for a long time) probably never caught it.
Patch by: David CARLIER
Reviewers: vitalybuka, krytarowski
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43502
llvm-svn: 325664
Summary:
forkpty(3) and openpty(3) are part of `-lutil` and we don't intend to reimplement
this system library in sanitizers. Everybody using these functions will need to use
a precompiled library against MSan or other desired sanitizer.
Restrict these functions to Linux-only.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D43490
llvm-svn: 325585
Summary:
Use uniform accessors for Program Pointer,
Stack Pointer and Frame Pointer.
Remove CPU check in UBSan supported platforms
and rely only on the OS type.
This adds NetBSD support in GetPcSpBp() for:
- ARM
- ARM64
- HPPA
- PowerPC/PowerPC64
- SPARC/SPARC64
- MIPS
- DEC Alpha AXP
- DEC VAX
- M68K and M68010
- SH3
- IA64
- OR1K
- RISCV
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, ro
Reviewed By: vitalybuka
Subscribers: aemerson, jyknight, sdardis, kubamracek, arichardson, llvm-commits, kristof.beyls, fedor.sergeev, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D43021
llvm-svn: 325431
The original change broke a llvm-clang-lld-x86_64-debian setup.
This change will be investigated and reintroduced in future.
Original commit:
"Add Xray instrumentation support to FreeBSD"
https://reviews.llvm.org/D43278
llvm-svn: 325309
It looks like get_bits_for_arch doesn't recognize "arm64" as a 64-bit architecture, and it actually matches the "arm" regexp, which marks it as 32-bit. Let's fix that by matching the 64-bit list first and addin "arm64" into the list.
Differential Revision: https://reviews.llvm.org/D43155
llvm-svn: 325300
NetBSD ships now with netbsd_syscall_hooks.h and requires support
for TSan specific features to be enabled.
This is follow up of:
D42048: Add NetBSD syscall hooks skeleton in sanitizers
Sponsored by <The NetBSD Foundation>
llvm-svn: 325245
Summary:
- Enabling the build.
- Using assembly for the cpuid parts.
- Using thr_self FreeBSD call to get the thread id
Patch by: David CARLIER
Reviewers: dberris, rnk, krytarowski
Reviewed By: dberris, krytarowski
Subscribers: emaste, stevecheckoway, nglevin, srhines, kubamracek, dberris, mgorny, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43278
llvm-svn: 325240
Summary:
Introduce handling of 1200 NetBSD specific ioctl(2) calls.
Over 100 operations are disabled as unavailable or conflicting
with the existing ones (the same operation number).
Add a script that generates the rules to detect ioctls on NetBSD.
The generate_netbsd_ioctls.awk script has been written
in NetBSD awk(1) (patched nawk) and is compatible with gawk.
Generate lib/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc
with the awk(1) script.
Update sanitizer_platform_limits_netbsd accordingly to add the needed
definitions.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, eugenis, dvyukov
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, mgorny, fedor.sergeev, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41636
llvm-svn: 325212
Summary:
Implement the skeleton of NetBSD syscall hooks for use with sanitizers.
Add a script that generates the rules to handle syscalls
on NetBSD: generate_netbsd_syscalls.awk. It has been written
in NetBSD awk(1) (patched nawk) and is compatible with gawk.
Generate lib/sanitizer_common/sanitizer_platform_limits_netbsd.h
that is a public header for applications, and included as:
<sanitizer_common/sanitizer_platform_limits_netbsd.h>.
Generate sanitizer_syscalls_netbsd.inc that defines all the
syscall rules for NetBSD. This file is modeled after the Linux
specific file: sanitizer_common_syscalls.inc.
Start recognizing NetBSD syscalls with existing sanitizers:
ASan, ESan, HWASan, TSan, MSan.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, dvyukov, eugenis
Reviewed By: vitalybuka
Subscribers: hintonda, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D42048
llvm-svn: 325206
Summary:
Pretty straightforward, returning the `WorkingSetSize` of a
`PROCESS_MEMORY_COUNTERS` structure. AFAIU, `GetProcessMemoryInfo` is in
`kernel32.lib` for Windows 7 and above. Support for earlier Windows versions
would require `psapi.lib`, but I don't think those are supported by ASan?
Reviewers: alekseyshl, rnk, vitalybuka
Reviewed By: vitalybuka
Subscribers: vitalybuka, kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42822
llvm-svn: 325020
Summary:
- Reland rL324263, this time allowing for a compile-time decision as to whether
or not use the 32-bit division. A single test is using a class map covering
a maximum size greater than 4GB, this can be checked via the template
parameters, and allows SizeClassAllocator64PopulateFreeListOOM to pass;
- `MaxCachedHint` is always called on a class id for which we have already
computed the size, but we still recompute `Size(class_id)`. Change the
prototype of the function to work on sizes instead of class ids. This also
allows us to get rid of the `kBatchClassID` special case. Update the callers
accordingly;
- `InitCache` and `Drain` will start iterating at index 1: index 0 contents are
unused and can safely be left to be 0. Plus we do not pay the cost of going
through an `UNLIKELY` in `MaxCachedHint`, and touching memory that is
otherwise not used;
- `const` some variables in the areas modified;
- Remove an spurious extra line at the end of a file.
Reviewers: alekseyshl, tl0gic, dberris
Reviewed By: alekseyshl, dberris
Subscribers: dberris, kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D43088
llvm-svn: 324906
Currently NanoTime() on Darwin is unimplemented and always returns 0. Looks like there's quite a few things broken because of that (TSan periodic memory flush, ASan allocator releasing pages back to the OS). Let's fix that.
Differential Revision: https://reviews.llvm.org/D40665
llvm-svn: 324847
On Darwin, we currently use forkpty to communicate with the "atos" symbolizer. There are several problems that fork or forkpty has, e.g. that after fork, interceptors are still active and this sometimes causes crashes or hangs. This is especially problematic for TSan, which uses interceptors for OS-provided locks and mutexes, and even Libc functions use those.
This patch replaces forkpty with posix_spawn. Since posix_spawn doesn't fork (at least on Darwin), the interceptors are not a problem. Additionally, this also fixes a latent threading problem with ptsname (it's unsafe to use this function in multithreaded programs). Yet another benefit is that we'll handle post-fork failures (e.g. sandbox disallows "exec") gracefully now.
Differential Revision: https://reviews.llvm.org/D40032
llvm-svn: 324846
textdomain is a part of -lintl on BSDs. In GLIBC it's in libc.
We assume that -lintl will need to be rebuilt with sanitizers
in order to sanitize programs using its features.
This is a proper continuation of D41013.
The original patch has been reverted (adding -lintl).
llvm-svn: 324810
Summary:
Allow for options to be defined at compile time, like is already the case for
other sanitizers, via `SCUDO_DEFAULT_OPTIONS`.
Reviewers: alekseyshl, dberris
Reviewed By: alekseyshl, dberris
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42980
llvm-svn: 324620
gcc resolves `__builtin_c?z` to `__c?zdi2` which leads to infinite
recursion. This problem has been observed for sparc64, mips64 and riscv.
Presumably this happens whenever an arch without dedicated bit counting
instructions is targeted. This patch provides a workaround.
Differential revision: https://reviews.llvm.org/D42902
llvm-svn: 324593
The test expects to see the pattern "load add store" twice
in a row.
However the test contains actually several instances of this pattern.
Currently the first pattern appears in the output twice.
But after LLVM change https://reviews.llvm.org/D42691 some addtional
modification is done and one of another pattern has been hoisted in
function entry block.
As a result we have another order of meeting this pattern.
The test is updated to meet this change.
llvm-svn: 324571
The original libFuzzer Fuchsia port relied on convenience libraries,
but these are not exported as part of Fuchsia sysroot. This change
eliminates the use of these libraries and relies on public API only.
Differential Revision: https://reviews.llvm.org/D42996
llvm-svn: 324454
Summary:
Before Xcode 4.5, undefined weak symbols don't work reliably on Darwin:
https://stackoverflow.com/questions/6009321/weak-symbol-link-on-mac-os-x
Therefore this patch disables their use before Mac OS X 10.9 which is the first version
only supported by Xcode 4.5 and above.
Reviewers: glider, kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41346
llvm-svn: 324284
Summary:
The 32-bit division breaks SizeClassAllocator64PopulateFreeListOOM which uses
Primary that has a maximum size > 32-bit.
Reviewers: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42928
llvm-svn: 324268
Summary:
In `ClassID`, make sure we use an unsigned as based for the `lbits` shift.
The previous code resulted in spurious sign extensions like for x64:
```
add esi, 0FFFFFFFFh
movsxd rcx, esi
and rcx, r15
```
The code with the `U` added is:
```
add esi, 0FFFFFFFFh
and rsi, r15
```
And for `MaxCachedHint`, use a 32-bit division instead of `64-bit`, which is
faster (https://lemire.me/blog/2017/11/16/fast-exact-integer-divisions-using-floating-point-operations/)
and already used in other parts of the code (64-bit `GetChunkIdx`, 32-bit
`GetMetaData` enforce 32-bit divisions)
Not major performance gains by any mean, but they don't hurt.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42916
llvm-svn: 324263
Summary:
Here are a few improvements proposed for the local cache:
- `InitCache` always read from `per_class_[1]` in the fast path. This was not
ideal as we are working with `per_class_[class_id]`. The latter offers the
same property we are looking for (eg: `max_count != 0` means initialized),
so we might as well use it and keep our memory accesses local to the same
`per_class_` element. So change `InitCache` to take the current `PerClass`
as an argument. This also makes the fast-path assembly of `Deallocate` a lot
more compact;
- Change the 32-bit `Refill` & `Drain` functions to mimic their 64-bit
counterparts, by passing the current `PerClass` as an argument. This saves
some array computations;
- As far as I can tell, `InitCache` has no place in `Drain`: it's either called
from `Deallocate` which calls `InitCache`, or from the "upper" `Drain` which
checks for `c->count` to be greater than 0 (strictly). So remove it there.
- Move the `stats_` updates to after we are done with the `per_class_` accesses
in an attempt to preserve locality once more;
- Change some `CHECK` to `DCHECK`: I don't think the ones changed belonged in
the fast path and seemed to be overly cautious failsafes;
- Mark some variables as `const`.
The overall result is cleaner more compact fast path generated code, and some
performance gains with Scudo (and likely other Sanitizers).
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42851
llvm-svn: 324257
The "sleep(5)" sometimes times out on our bots, causing the test to fail. Let's use pthread_join.
Differential Revision: https://reviews.llvm.org/D42862
llvm-svn: 324126
Late fix for SVN r. 324034
Add new interceptors: strlcpy(3) and strlcat(3)
There was forgotten an addition of len to the return value.
llvm-svn: 324091
Summary:
Implement `MonotonicNanoTime` using `QueryPerformanceCounter`.
This function is used by Scudo & the 64-bit Primary allocator. Implementing it
now means that the release-to-OS mechanism of the Primary will kick in (it
never did since the function returned 0 always), but `ReleaseMemoryPagesToOS` is
still not currently implemented for Windows.
Performance wise, this adds a syscall & a 64-bit division per call to
`MonotonicNanoTime` so the impact might not be negligible, but I don't think
there is a way around it.
Reviewers: rnk, alekseyshl, amccarth
Reviewed By: alekseyshl, amccarth
Subscribers: amccarth, flowerhack, kubamracek, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42579
llvm-svn: 324011
Summary:
Few changes to the secondary:
- mark `const` variables as such;
- change some `CHECK` to `DCHECK`: I don't feel we need to be as conservative as
we were with out checks, as they are the results of our own computation.
- mark a condition as `UNLIKELY`.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42696
llvm-svn: 323997
Summary:
With the change, one can choose not to report comparison (or subtraction)
of a pointer with nullptr pointer.
Reviewers: kcc, jakubjelinek, alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D41479
llvm-svn: 323995
This avoids the warnings when building with LLVM_ENABLE_LIBCXX
which automatically adds -stdlib=libc++ to CMAKE_CXX_FLAGS.
Differential Revision: https://reviews.llvm.org/D42238
llvm-svn: 323969
Summary:
This change expands the amount of registers stashed by the entry and
`__xray_CustomEvent` trampolines.
We've found that since the `__xray_CustomEvent` trampoline calls can show up in
situations where the scratch registers are being used, and since we don't
typically want to affect the code-gen around the disabled
`__xray_customevent(...)` intrinsic calls, that we need to save and restore the
state of even the scratch registers in the handling of these custom events.
Reviewers: pcc, pelikan, dblaikie, eizan, kpw, echristo, chandlerc
Reviewed By: echristo
Subscribers: chandlerc, echristo, hiraditya, davide, dblaikie, llvm-commits
Differential Revision: https://reviews.llvm.org/D40894
llvm-svn: 323940
This change updates the Fuchsia-specific code to use the C++ friendly
duration expressions and flips on the building of
libclang_rt.fuzzer-x86_64.a and similar for Fuchsia. Given that
compiler-rt doesn't build on Fuchsia, test have been run by explicitly
building the library and linking it against
lib/fuzzer/tests/FuzzerUnittest.cpp.
Differential Revision: https://reviews.llvm.org/D42670
llvm-svn: 323828
Summary:
This is in preparation for platforms where `SANITIZER_SUPPORTS_WEAK_HOOKS` is 0.
They require a default implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42557
llvm-svn: 323795
Summary:
Turns out sizeof(packed) isn't as strong as we'd hoped. This makes sure
that when we initialize the padding, all 12 bytes will be zero.
Reviewers: dberris, kpw, eizan
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42494
llvm-svn: 323755
There was a failure on a bot:
http://lab.llvm.org:8011/builders/clang-cmake-mipsel/builds/1283
strerror test is indeed flaky. We protect all races by a barrier in other tests
to eliminate flakiness. Do the same here.
No idea why tls_race2.cc failed. Add output at the end of the test
as we do in other tests. Sometimes test process crashes somewhere
in the middle (e.g. during race reporting) and it looks like empty output.
Output at the end of test allows to understand if the process has crashed,
or it has finished but produced no race reports.
Reviewed in https://reviews.llvm.org/D42633
llvm-svn: 323657
`set_target_compile_flags()` ultimately sets COMPILE_FLAGS which is
added to CMAKE_CXX_FLAGS in the compile rule, so passing
CMAKE_CXX_FLAGS causes them to be duplicated.
Differential Revision: https://reviews.llvm.org/D42398
llvm-svn: 323626
This gets rid of a lit warning (input './projects/compiler-rt/test/xray/Unit' contained no tests).
Differential Revision: https://reviews.llvm.org/D42597
llvm-svn: 323613
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42462
llvm-svn: 323606
Summary:
This is a follow-up to D42506.
There are a few of things that bothered me about `scudo_interceptors.cpp`:
- the filename is a misnomer: it intercepts some functions, but the rest (C++)
is actually in `scudo_new_delete.cpp`. I feel like `scudo_malloc.cpp` is more
appropriate (ASan uses the same naming scheme);
- we do not need "full" interceptors, since we are never accessing the
unsanitized version of the functions, we just need the
`extern "C" INTERCEPTOR_ATTRIBUTE` part of it to just call our functions;
- a couple of functions where duplicated while they could just be `ALIAS`'d;
- use the `SANITIZER_INTERCEPT_*` defines to hide the unneeded interceptors;
- use `SIZE_T` instead of `uptr`: while it's the same behind the curtain,
the former is meant for this use case.
In the end there is no functional change on the currently supported platforms
(Linux, Android).
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, hintonda, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42546
llvm-svn: 323464
Summary:
Implement `GetNumberOfCPUs` using `GetNativeSystemInfo`.
The only consummer of this function is Scudo which is not functional on
Windows yet.
Reviewers: rnk, zturner
Reviewed By: zturner
Subscribers: zturner, kubamracek, delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42547
llvm-svn: 323462
Summary:
Currently all platforms are using the `scudo_interceptors.cpp` interceptors.
We might to come up with platform specific interceptors when/if we get Apple &
Windows, but as of now, that allows for Fuchsia to use them.
`scudo_new_delete.cpp` didn't have the `#if SANITIZER_LINUX` so it's good to go.
Reviewers: alekseyshl, flowerhack
Reviewed By: flowerhack
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42506
llvm-svn: 323386
Summary:
Hooks in the allocation & deallocation paths can be a security risk (see for an
example https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-advancing-exploitation.html
which used the glibc's __free_hook to complete exploitation).
But some users have expressed a need for them, even if only for tests and
memory benchmarks. So allow for `__sanitizer_malloc_hook` &
`__sanitizer_free_hook` to be called if defined, and gate them behind a global
define `SCUDO_CAN_USE_HOOKS` defaulting to 0.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42430
llvm-svn: 323278
Summary:
Now that ubsan does function interception (for signals), we
need to ensure that ubsan is initialized before any library
constructors are called. Otherwise, if a constructor calls
sigaction, ubsan will intercept in an unitialized state, which
will cause a crash.
This patch is a partial revert of r317757, which removed
preinit arrays for ubsan.
Reviewers: vitalybuka, eugenis, pcc
Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42389
llvm-svn: 323249
In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the address sanitizer to not work properly. This
patch fixes up a test case that was found to fail on some newer Fedora
releases that use different address ranges.
ref: https://reviews.llvm.org/D40907
llvm-svn: 323217
Summary:
One test-case uses a wrong operation (should be subtraction).
Second test-case should declare a global variables before a tested one
in order to guarantee we will find a red-zone.
Reviewers: kcc, jakubjelinek, alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D41481
llvm-svn: 323162
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323054
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323032
sequentially.
The current implementation of commands in
`test/sanitizer_common/ios_commands/` for iOS devices cannot be executed
in parallel which results in the ASan and TSan tests failing when
executed in parallel by lit which was the default behaviour.
We now force the ASan and TSan tests to be a new parallelism group named
`darwin-ios-device-sanitizer` which allows only one test to be run at a
time. We also emit a warning informing the user that tests are being
run sequentially.
This only applies if the target is an iOS device.
Differential Revision: https://reviews.llvm.org/D42156
llvm-svn: 323026
MemToShadowImpl() maps lower addresses to a memory space out of sanitizers
range. The simplest example is address 0 which is mapped to 0x2000000000
static const uptr kShadowBeg = 0x2400000000ull;
but accessing the address during tsan execution will lead to a segmentation
fault.
This patch expands the range used by the sanitizer and ensures that 1/8 of
the maximum valid address in the virtual address spaces is used for shadow
memory.
Patch by Milos Stojanovic.
Differential Revision: https://reviews.llvm.org/D41777
llvm-svn: 323013
Summary:
We somehow never did it, and it raised no issue until now, when trying to
enable Fuchsia as a supported Scudo platform in the cmake config.
So propagate SANITIZER_COMMON_LINK_FLAGS for now.
Reviewers: alekseyshl, flowerhack
Reviewed By: flowerhack
Subscribers: mgorny, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42314
llvm-svn: 322999
Summary:
While there, unify InMemoryRawLog and InMemoryRawLogWithArg's coding style:
- swap libc's memcpy(3) for sanitizer's internal memcpy
- use basic pointer arithmetics to compute offsets from the first record
entry in the pre-allocated buffer, which is always the appropriate type
for the given function
- lose the local variable references as the TLD.* names fit just as well
Reviewers: eizan, kpw, dberris, dblaikie
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42289
llvm-svn: 322941
Generalize this handling to a separate toplevel ifdef (since any
windows case should use the same function), instead of indenting
the aarch64 case one step further.
Differential Revision: https://reviews.llvm.org/D42197
llvm-svn: 322928
Summary:
Tests were being run by whole-linking the static library with our test binaries.
But since `-fsanitize=scudo` landed with rL317337, we might as well change how
the tests are compiled to use it.
The only difference will be on Android, where the clang flag links in the
dynamic library instead, but the bots are already pushing
`libclang_rt.*-android.so` to the device there is no additional change needed.
Tested locally, including with a standalone build, and an Android one on a O
device, and it all passes.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42243
llvm-svn: 322882
Summary:
Make common allocator agnostic to failure handling modes and move the
decision up to the particular sanitizer's allocator, where the context
is available (call stack, parameters, return nullptr/crash mode etc.)
It simplifies the common allocator and allows the particular sanitizer's
allocator to generate more specific and detailed error reports (which
will be implemented later).
The behavior is largely the same, except one case, the violation of the
common allocator's check for "size + alignment" overflow is now reportied
as OOM instead of "bad request". It feels like a worthy tradeoff and
"size + alignment" is huge in this case anyway (thus, can be interpreted
as not enough memory to satisfy the request). There's also a Report()
statement added there.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42198
llvm-svn: 322784
Summary:
A forgotten include in `scudo_allocator.cpp` made the symbol only local :/
Before:
```
nm ./lib/clang/7.0.0/lib/linux/libclang_rt.scudo-i686-android.so | grep rss
00024730 t __scudo_set_rss_limit
```
After:
```
nm ./lib/clang/7.0.0/lib/linux/libclang_rt.scudo-i686-android.so | grep rs
00024760 T __scudo_set_rss_limit
```
And we want `T`!
This include also means that we can get rid of the `extern "C"` in the C++
file, the compiler does fine without it (note that this was already the case
for all the `__sanitizer_*` interface functions.
Reviewers: alekseyshl, eugenis
Reviewed By: eugenis
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42199
llvm-svn: 322782
Summary:
jemalloc on Android currently uses 2 arenas
(https://android.googlesource.com/platform/external/jemalloc/+/master/Android.bp#64).
Since the Android toolchain absorbs compiler-rt and compiles it as is, we have
to enforce the same limit to somehow stay competitive in terms of memory usage.
The changes could either go in:
- `scudo_platform.h` with a default for Android of 2 (this is the solution
implemented here);
- in `CMakeLists.txt` adding -DSCUDO_SHARED_TSD_POOL_SIZE=2 for Android.
- something else?
I don't have a strong opinion on how to do it, but it has to be done upstream
anyway.
Reviewers: alekseyshl, eugenis
Reviewed By: alekseyshl, eugenis
Subscribers: srhines, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D42194
llvm-svn: 322764
This is needed in case the users of libFuzzer use libc++ in their
code, which the fuzz target (libFuzzer) will be linked against.
When libc++ source is available, we build a private version of it
and link it against libFuzzer which allows using the same static
library against codebases which use both libc++ and libstdc++.
Differential Revision: https://reviews.llvm.org/D37631
llvm-svn: 322755
Summary:
This patch (on top of the previous two (https://reviews.llvm.org/D40898 and
https://reviews.llvm.org/D40899) complete the compiler-rt side of the the Solaris
sanitizer port.
It contains the following sets of changes:
* For the time being, the port is for 32-bit x86 only, so reject the various tests on
x86_64.
* When compiling as C++, <setjmp.h> resp. <iso/setjmp_iso.h> only declares
_setjmp and _longjmp inside namespace std.
* MAP_FILE is a Windows feature. While e.g. Linux <sys/mman.h> provides a
no-op compat define, Solaris does not.
* test/asan/TestCases/Posix/coverage.cc was initially failing like this:
/vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py: 4 files merged; 2 PCs total
rm: cannot remove '/var/gcc/llvm/local/projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Posix/Output/coverage': Invalid argument
Further digging revealed that the rm was trying to remove the running test's working
directory which failed as observed. cd'ing out of the dir before let the test pass.
* Two tests needed a declaration of alloca. I've now copied the existing code from
test/asan/TestCases/alloca_constant_size.cc, but it may be more profitable and
maintainable to have a common testsuite header where such code is collected.
* Similarly, Solaris' printf %p format doesn't include the leading 0x.
* In test/asan/TestCases/malloc-no-intercept.c, I had to undef __EXTENSIONS__
(predefined by clang for no apparent reason) to avoid conflicting declarations
for memalign.
* test/ubsan/TestCases/Float/cast-overflow.cpp has different platform dependent
ways to define BYTE_ORDER and friends. Why not just use __BYTE_ORDER__ and
friends as predefined by clang and gcc?
Patch by Rainer Orth.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, krytarowski, fedor.sergeev, JDevlieghere, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40900
llvm-svn: 322635
This is needed in case the users of libFuzzer use libc++ in their
code, which the fuzz target (libFuzzer) will be linked against.
When libc++ source is available, we build a private version of it
and link it against libFuzzer which allows using the same static
library against codebases which use both libc++ and libstdc++.
Differential Revision: https://reviews.llvm.org/D37631
llvm-svn: 322604
Summary: -fPIE can not be used when building a shared library.
Reviewers: alekseyshl, peter.smith
Subscribers: kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D42121
llvm-svn: 322588
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322451
Summary:
Some time ago, the sanitizers as of r315899 were imported into gcc mainline. This broke
bootstrap on Darwin 10 and 11, as reported in GCC PR sanitizer/82824
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824) due to the unconditional use
of VM_MEMORY_OS_ALLOC_ONCE. This was only introduced in Darwin 13/Mac OS X 10.9.
The use of the macro was introduced in r300450.
I couldn't find any statement which Darwin versions are supposed to be supported by
LLVM, but the trivial patch to use the macro only if present allowed the gcc bootstrap
to finish.
So far, I haven't tried building llvm/compiler-rt on Darwin 11. Maybe the patch is
simple enough to go in nonetheless.
Committing on behalf of ro.
Reviewers: glider, fjricci, kcc, kuba, kubamracek, george.karpenkov
Reviewed By: fjricci
Subscribers: #sanitizers, zaks.anna, srhines, dberris, kubamracek, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39888
llvm-svn: 322437
Summary: It is not necessary launching the build script with bash.
Reviewers: krytarowski
Reviewed By: krytarowski
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42008
llvm-svn: 322422
Summary:
itimerval can contain padding that may be legitimately uninitialized.
On NetBSD there are four integers of type "long, int, long, int", the
int argument stands for __sanitizer_suseconds_t. Compiler adds extra
padding in this layout.
Check every field of struct itimerval separately.
Define __sanitizer_suseconds_t as long on FreeBSD, Linux and SmartOS,
and int on NetBSD. Define __sanitizer_timeval and __sanitizer_itimerval.
Sponsored by <The NetBSD Foundation>
Reviewers: eugenis, joerg, vitalybuka
Reviewed By: vitalybuka
Subscribers: emaste, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41502
llvm-svn: 322399
Summary:
This is needed for the shared runtime since we are pulling RTUbsan in.
Otherwise some builds might fail with errors such as:
`error: undefined reference to '__dynamic_cast'`
Reviewers: alekseyshl, srhines
Reviewed By: srhines
Subscribers: kongyi, pirama, chh, mgorny, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D41995
llvm-svn: 322389
Summary:
Very basic stack instrumentation using tagged pointers.
Tag for N'th alloca in a function is built as XOR of:
* base tag for the function, which is just some bits of SP (poor
man's random)
* small constant which is a function of N.
Allocas are aligned to 16 bytes. On every ReturnInst allocas are
re-tagged to catch use-after-return.
This implementation has a bunch of issues that will be taken care of
later:
1. lifetime intrinsics referring to tagged pointers are not
recognized in SDAG. This effectively disables stack coloring.
2. Generated code is quite inefficient. There is one extra
instruction at each memory access that adds the base tag to the
untagged alloca address. It would be better to keep tagged SP in a
callee-saved register and address allocas as an offset of that XOR
retag, but that needs better coordination between hwasan
instrumentation pass and prologue/epilogue insertion.
3. Lifetime instrinsics are ignored and use-after-scope is not
implemented. This would be harder to do than in ASan, because we
need to use a differently tagged pointer depending on which
lifetime.start / lifetime.end the current instruction is dominated
/ post-dominated.
Reviewers: kcc, alekseyshl
Subscribers: srhines, kubamracek, javed.absar, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41602
llvm-svn: 322324
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322256
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322234
Summary:
Enable the compile-time flag -fsanitize-memory-use-after-dtor by
default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1
still needs to be enabled for destructors to be poisoned.
Reviewers: eugenis, vitalybuka, kcc
Reviewed By: eugenis, vitalybuka
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37860
llvm-svn: 322221
Summary:
Avoid flaky test failures by by using a monotonic number sequence of
heap tags.
Does not affect stack tags: the way we generate those guarantees
uniqueness for at least 30-something first allocas in any function,
as well as the UAR tag.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D41882
llvm-svn: 322214
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322153
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
This change removes exception specifications from the function types recorded
for -fsanitize=function, both in the functions themselves and at the call sites.
That means that calling a non-noexcept function through a noexcept pointer will
also not be flagged as UB. In the review of this change, that was deemed
acceptable, at least for now. (See the "TODO" in compiler-rt
test/ubsan/TestCases/TypeCheck/Function/function.cpp.)
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 321860
NDK < 13 & API_LEVEL < 21 do not define struct mmsghdr.
Newer NDK use unified headers and provide this definition for all api
levels.
Since we can not check for the NDK version, check the api level. This
is more strict than absolutely necessary, but it does not really
matter: it is only a sanity check.
llvm-svn: 321817
Summary:
It used to fail on the bots, but I could not repro it locally. So turn it back
on to try and see if it still fails and maybe get to the heart of it.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: aemerson, srhines, kristof.beyls, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D41707
llvm-svn: 321812
Summary:
`__scudo_set_rss_limit`'s `LimitMb` should really be a `size_t`. Update
accordingly the prototype. To avoid the `NOLINT` and conform with the other
Sanitizers, use the sanitizers types for the internal definition. This should
have no functional change.
Additionally, capitalize a variable name to follow the LLVM coding standards.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41704
llvm-svn: 321803
We're having some use cases where we have more than 128 (the current maximum) instrumented dynamic libraries loaded into a single process. Let's bump the limit to 1024, and separate the constants.
Differential Revision: https://reviews.llvm.org/D41190
llvm-svn: 321782
Summary: Extend the sendmsg test to cover all recv*.
Reviewers: vitalybuka
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D41620
llvm-svn: 321774
Summary:
This way new asan_device_setup, which knows about the quirks of
recent releases of Android, can be used with older ASan runtime
library (say, from an NDK release). The library is version locked to
the compiler, and is often hard or impossible to update.
Reviewers: vitalybuka
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D41679
llvm-svn: 321677
This macro is only defined after XCode 8, causing build breakage for
build systems with prior versions. Ignore DISPATCH_NOESCAPE if not
defined.
Differential Revision: https://reviews.llvm.org/D41601
llvm-svn: 321543
...when such an operation is done on an object during con-/destruction.
(This adds a test case to compiler-rt/test/ubsan/TestCases/TypeCheck/vptr.cpp
that, unlike the existing test cases there, wants to detect multiple UBSan
warnings in one go. Therefore, that file had to be changed from globally using
-fno-sanitize-recover to individually using halt_on_error only where
appropriate.)
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40295
llvm-svn: 321518
FDRLoggingTest::MultiThreadedCycling uses std::array so we need to
include the right C++ header and not rely on transitive dependencies.
llvm-svn: 321485
As reported in PR35739, rL252927 added the Windows specific chkstk and
chkstk2 sources unconditionally, and since these are assembly without a
NO_EXEC_STACK_DIRECTIVE at the end, automated vulnerability scanners
warned about the objects having an executable stack.
Avoid the problem by only including these files when Windows is
targeted.
Reviewers: compnerd, rnk, martell
Reviewed By: martell
Subscribers: mstorsjo, mgorny, martell, javed.absar, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41567
llvm-svn: 321431
Summary:
Export aligned new/delete to make dynamic runtimes work again.
Remove all valid new/delete cases from ASan test, there's a test in
common for that.
Reviewers: eugenis
Subscribers: srhines, kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41548
llvm-svn: 321394
r318733 introduced a build failure for native MIPS32 systems for xray due
to the lack of __sync_fetch_and_add / __syn_fetch_and_sub support. This patch
extends the existing support providing atomics so that xray can be
successfully built.
The initial patch was reverted in r321292, as I suspected it may have caused the
buildbot failure. Another patch in the updates the bot fetched caused the test
failures which was reverted.
Reviewers: atanasyan, dberris
Differential Revision: https://reviews.llvm.org/D40385
llvm-svn: 321383
Summary:
This patch, on top of https://reviews.llvm.org/D40898, contains the build system
changes necessary to enable the Solaris/x86 sanitizer port.
The only issue of note is the libclang_rt.sancov_{begin, end} libraries: clang relies on the
linker automatically defining __start_SECNAME and __stop_SECNAME labels for
sections whose names are valid C identifiers. This is a GNU ld extension not present
in the ELF gABI, also implemented by gold and lld, but not by Solaris ld. To work around
this, I automatically link the sancov_{begin,end} libraries into every executable for now.
There seems to be now way to build individual startup objects like crtbegin.o/crtend.o,
so I've followed the lead of libclang_rt.asan-preinit which also contains just a single
object.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, mgorny, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40899
llvm-svn: 321373
Summary:
Providing aligned new/delete implementations to match ASan.
Unlike ASan, MSan and TSan do not perform any additional checks
on overaligned memory, hence no sanitizer specific tests.
Reviewers: eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41532
llvm-svn: 321365
The public sanitizer headers are intended to be usable from either
C++ or C, but they declare no-argument functions with the syntax that
is not a proper prototype declaration in C. This goes unnoticed until
someone uses -Wsystem-headers.
Patch By: mcgrathr
Reviewers: phosek, vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D41475
llvm-svn: 321305
r318733 introduced a build failure for native MIPS32 systems for xray due
to the lack of __sync_fetch_and_add / __syn_fetch_and_sub support. This patch
extends the existing support providing atomics so that xray can be
successfully built.
Reviewers: atanasyan, dberris
Differential Revision: https://reviews.llvm.org/D40385
llvm-svn: 321260
Summary: Very similar to AddressSanitizer, with the exception of the error type encoding.
Reviewers: kcc, alekseyshl
Subscribers: cfe-commits, kubamracek, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D41417
llvm-svn: 321203
There could be a situation when a specific DSO was built with FORTIFY_SOURCE option. In case asan-ed binary link against that DSO,
libasan can't handle the possible memory error because it does not have interceptors for spinrtf_chk, snprintf_chk, vprintf_chk,
vsnprintf_chk, __fprintf_chk functions. Let's interceptors for them.
Patch by Denis Khalikov.
Differential Revision: https://reviews.llvm.org/D40951
llvm-svn: 320990
At least <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/
builds/6013/steps/annotate/logs/stdio> complains about
__ubsan::__ubsan_handle_function_type_mismatch_abort (compiler-rt
lib/ubsan/ubsan_handlers.cc) returning now despite being declared 'noreturn', so
looks like a different approach is needed for the function_type_mismatch check
to be called also in cases that may ultimately succeed.
llvm-svn: 320981
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
There is no cheap check whether two function type_infos only differ in noexcept,so pass those two type_infos as additional data to the function_type_mismatch
handler (with the optimization of passing a null "static callee type" info when that is already noexcept, so the additional check can be avoided anyway). For
the Itanium ABI (which appears to be the only one that happens to be used on
platforms that support -fsanitize=function, and which appears to only record
noexcept information for pointer-to-function type_infos, not for function
type_infos themselves), we then need to check the mangled names for occurrence
of "Do" representing "noexcept".
This is the compiler-rt part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 320977
Summary:
https://reviews.llvm.org/D41121 broke the FreeBSD build due to that type not
being defined on FreeBSD. As far as I can tell, it is an int, but I do not have
a way to test the change.
Reviewers: alekseyshl, kparzysz
Reviewed By: kparzysz
Subscribers: kparzysz, emaste, kubamracek, krytarowski, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41325
llvm-svn: 320931
Summary:
Hook on -DKERNEL_USE (which is also used in lib/builtins) to not import
strlen and not rely on write() being implemented with the stderr on fd 2.
With this, the only requirements to use this library are:
- "Good enough" std::atomic<void*> and std::atomic<int>
- abort() being implemented
- ubsan_message(const char*) being implemented
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39791
llvm-svn: 320831
Summary:
This patch adds a new install target `install-compilert-rt-headers`,
that is similar to `install-clang-headers`.
It allows to install the headers without installing all of
compiler-rt.
Reviewers: alekseyshl, beanz
Reviewed By: beanz
Subscribers: smeenai, beanz, mgorny, #sanitizers, kcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D41244
llvm-svn: 320808
Summary:
The initial implementation used an ASan like Chunk class that was deriving from
a Header class. Due to potential races, we ended up working with local copies
of the Header and never using the parent class fields. ScudoChunk was never
constructed but cast, and we were using `this` as the pointer needed for our
computations. This was meh.
So we refactored ScudoChunk to be now a series of static functions within the
namespace `__scudo::Chunk` that take a "user" pointer as first parameter (former
`this`). A compiled binary doesn't really change, but the code is more sensible.
Clang tends to inline all those small function (in -O2), but GCC left a few not
inlined, so we add the `INLINE` keyword to all.
Since we don't have `ScudoChunk` pointers anymore, a few variables were renamed
here and there to introduce a clearer distinction between a user pointer
(usually `Ptr`) and a backend pointer (`BackendPtr`).
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41200
llvm-svn: 320745
Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.
This part was initially developed inside libsanitizer in the GCC tree and should apply to
both. Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.
I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.
Most of the changes are probably straightforward with a few exceptions:
* The Solaris syscall interface isn't stable, undocumented and can change within an
OS release. The stable interface is the libc interface, which I'm using here, if possible
using the internal _-prefixed names.
* While the patch primarily target 32-bit x86, I've left a few sparc changes in. They
cannot currently be used with clang due to a backend limitation, but have worked
fine inside the gcc tree.
* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.
The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11. Only a few failures remain, some of them analyzed, some
still TBD:
AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations
Maybe this is good enough the get the ball rolling.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40898
llvm-svn: 320740
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Hopefully the Windows support is fixed now.
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320731
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320726
Summary:
Before this change, XRay would conservatively patch sections of the code
one sled at a time. Upon testing/profiling, this turns out to take an
inordinate amount of time and cycles. For an instrumented clang binary,
the cycles spent both in the patching/unpatching routine constituted 4%
of the cycles -- this didn't count the time spent in the kernel while
performing the mprotect calls in quick succession.
With this change, we're coalescing the number of calls to mprotect from
being linear to the number of instrumentation points, to now being a
lower constant when patching all the sleds through `__xray_patch()` or
`__xray_unpatch()`. In the case of calling `__xray_patch_function()` or
`__xray_unpatch_function()` we're now doing an mprotect call once for
all the sleds for that function (reduction of at least 2x calls to
mprotect).
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41153
llvm-svn: 320664
Summary:
Changes:
- Don't attempt to intercept GLIBC specific functions like __strtol_internal.
This is required to stop intercepting it as we leak dlerror(3) for dlsym(3)
that cannot manage to find a symbol.
- Correct interception of fstatat(2).
- Don't run a test for fgetgrent_r() that is missing on NetBSD.
- Correct link_map location (offset) in Obj_Entry on x86_64 and i386.
- Stop intercepting getpshared-like functions in pthread(3). This is feature
is not enabled by default on NetBSD as it's unfinished.
- Switch intercepting from UTMP to UTMPX functions.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, eugenis, kcc
Reviewed By: vitalybuka
Subscribers: llvm-commits, srhines, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41053
llvm-svn: 320663
This saves ~2 MB of dirty memory footprint. Can be a big deal on mobile devices especially when running multiple processes with ASan.
Differential Revision: https://reviews.llvm.org/D40627
llvm-svn: 320660
MADV_DONTNEED on Linux actually mark the pages as free to be overwritten with zeroes, but on Darwin and BSD, it's just an advisory flag (the OS cannot discard the content). We should use MADV_FREE on Darwin and BSD.
Differential Revision: https://reviews.llvm.org/D40666
llvm-svn: 320659
Summary:
Add dummy call of LLVMFuzzerTestOneInput to afl_driver before it starts
executing on actual inputs. Do this so that first time initialization
performed by LLVMFuzzerTestOneInput is not considered code covered by
a particular input.
Patch By: metzman
Reviewers: kcc, morehouse
Reviewed By: kcc
Subscribers: llvm-commits, Sanitizers
Differential Revision: https://reviews.llvm.org/D41193
llvm-svn: 320643
Summary:
The first and only function to start with allows to set the soft or hard RSS
limit at runtime. Add associated tests.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: mgorny, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D41128
llvm-svn: 320611
Summary:
See D40657 & D40679 for previous versions of this patch & description.
A couple of things were fixed here to have it not break some bots.
Weak symbols can't be used with `SANITIZER_GO` so the previous version was
breakin TsanGo. I set up some additional local tests and those pass now.
I changed the workaround for the glibc vDSO issue: `__progname` is initialized
after the vDSO and is actually public and of known type, unlike
`__vdso_clock_gettime`. This works better, and with all compilers.
The rest is the same.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, kubamracek, krytarowski, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D41121
llvm-svn: 320594
Summary:
getScudoChunk function is implicitly inlined for optimized builds on
clang, but not on gcc. It's a small enough function that it seems
sensible enough to just inline it by default.
Reviewers: cryptoad, alekseyshl
Reviewed By: cryptoad
Differential Revision: https://reviews.llvm.org/D41138
llvm-svn: 320592
This change makes XRay print the log file output only when the verbosity
level is higher than 0. It reduces the log spam in the default case when
we want XRay running silently, except when there are actual
fatal/serious errors.
We also update the documentation to show how to get the information
after the change to the default behaviour.
llvm-svn: 320550
Summary: This brings CPU overhead on bzip2 down from 5.5x to 2x.
Reviewers: kcc, alekseyshl
Subscribers: kubamracek, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41137
llvm-svn: 320538
This also slightly refactors the code that's checking the directory
presence which allows eliminating one unnecessary variable.
Differential Revision: https://reviews.llvm.org/D40637
llvm-svn: 320446
Summary:
Redo of D40657, which had the initial discussion. The initial code had to move
into a libcdep file, and things had to be shuffled accordingly.
`NanoTime` is a time sink when checking whether or not to release memory to
the OS. While reducing the amount of calls to said function is in the works,
another solution that was found to be beneficial was to use a timing function
that can leverage the vDSO.
We hit a couple of snags along the way, like the fact that the glibc crashes
when clock_gettime is called from a preinit_array, or the fact that
`__vdso_clock_gettime` is mangled (for security purposes) and can't be used
directly, and also that clock_gettime can be intercepted.
The proposed solution takes care of all this as far as I can tell, and
significantly improve performances and some Scudo load tests with memory
reclaiming enabled.
@mcgrathr: please feel free to follow up on
https://reviews.llvm.org/D40657#940857 here. I posted a reply at
https://reviews.llvm.org/D40657#940974.
Reviewers: alekseyshl, krytarowski, flowerhack, mcgrathr, kubamracek
Reviewed By: alekseyshl, krytarowski
Subscribers: #sanitizers, mcgrathr, srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D40679
llvm-svn: 320409
Summary:
Include <sys/tls.h> for:
- struct tls_tcb - thread control block structure
- __HAVE___LWP_GETTCB_FAST - __lwp_gettcb_fast() is available
- __HAVE___LWP_GETPRIVATE_FAST - __lwp_getprivate_fast() is available
- __HAVE_TLS_VARIANT_I - TLS Variant I for this architecture
- __HAVE_TLS_VARIANT_II - TLS Variant II for this architecture
Rename ThreadSelfSegbase() to ThreadSelfTlsTcb and switch it
to retrieve in a portable way TCB.
Switch ThreadSelf() to retrieve pthread from struct tcb_tls.
Use dl_iterate_phdr() to find out the size of TLS block of
the main program.
Correct the index of the TLS block of the main program
(dlpi_tls_modid); it's 1, not 2.
New NetBSD code is now CPU (NetBSD port) agnostic.
Stop sharing the same code with FreeBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: dvyukov, joerg, vitalybuka
Reviewed By: vitalybuka
Subscribers: emaste, kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40159
llvm-svn: 320234
Summary:
This tests must be linked with -lintl for the gettext(3) features.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41013
llvm-svn: 320226
Summary:
This test uses GNU-specific extension to libc: tdestroy() and as-is is not compatible with NetBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41011
llvm-svn: 320225
Summary:
Reuse the Linux new mapping as it is.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, eugenis
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41023
llvm-svn: 320218
Summary:
This patch adds the initial support for Fuchsia.
- LIBFUZZER_FUCHSIA is added as an OS type in FuzzerDefs.h
- Fuchsia is, by design, not POSIX compliant. However, it does use ELF and
supports common POSIX I/O functions. Thus, FuzzerExtFunctions.h and
FuzzerIO.h are implemented by extending the header guards in
FuzzerExtFunctionsWeak.cpp and FuzzerIOPosix.cpp to include
LIBFUZZER_FUCHSIA.
- The platform-specific portions of FuzzerUtil.h are implemented by
FuzzerUtilFuchsia.cpp, which makes use of exception ports, syscalls, and
the launchpad library.
- The experimental equivalence server is not currently supported, so
FuzzerShmem.h is implemented by stub methods in FuzzerShmemFuchsia.cpp.
Any future implementation will likely involve VMOs.
Tested with ASAN/SanCov on Fuchsia/x86-64 with the canonical toy fuzzer.
Patch By: aarongreen
Reviewers: kcc, morehouse, flowerhack, phosek
Reviewed By: kcc, phosek, Eugene.Zelenko
Subscribers: srhines, mgorny, Eugene.Zelenko
Differential Revision: https://reviews.llvm.org/D40974
llvm-svn: 320210
Summary:
It looks like clang was generating somewhat weird assembly with the current
code. `FromPrimary`, even though `const`, was replaced every time with the code
generated for `size <= SizeClassMap::kMaxSize` instead of using a variable or
register, and `FromPrimary` didn't induce `ClassId != 0` for the compiler, so a
dead branch was generated for `getActuallyAllocatedSize(Ptr, ClassId)` since
it's never called for `ClassId = 0` (Secondary backed allocations) [this one
was more wishful thinking on my side than anything else].
I rearranged the code bit so that the generated assembly is less clunky.
Also changed 2 whitespace inconsistencies that were bothering me.
Reviewers: alekseyshl, flowerhack
Reviewed By: flowerhack
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D40976
llvm-svn: 320160
In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the address sanitizer to not work properly. This
patch adds support for 47 bit VMA kernels for powerpc64 and fixes up test
cases.
https://reviews.llvm.org/D40908
There is an associated patch for trunk.
Tested on several 4.x and 3.x kernel releases.
llvm-svn: 320110
Summary: With 3 Dictionary objects, each containing space of ~16k DictionaryEntry objects, the MutationDispatcher object is fairly memory heavy. On platforms with a lower default stack size, this can cause panics in FuzzerUnittest as those tests stack-allocate the MutationDispatcher. This may be especially problematic for platforms that do not (yet) have a way to programmatically change their stack size, aside from link-time flags. In general, it seems more prudent to use the heap for an object of this size.
Reviewers: kcc, morehouse
Reviewed By: kcc
Differential Revision: https://reviews.llvm.org/D40926
llvm-svn: 319988
Summary:
The NetBSD specific implementation of cxa_atexit() does not
preserve the 2nd argument if dso is equal to NULL.
Changes:
- Split paths of handling intercepted __cxa_atexit() and atexit(3).
This affects all supported Operating Systems.
- Add a local stack-like structure to hold the __cxa_atexit() context.
atexit(3) is documented in the C standard as calling callback from the
earliest to the oldest entry. This path also fixes potential ABI
problem of passing an argument to a function from the atexit(3)
callback mechanism.
- Allow usage of global vars with ctors in interceptors.
This allows to use Vector without automatic cleaning up the structures.
This code has been modeled after TSan implementation for the same functions.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, eugenis, vitalybuka, kcc
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40714
llvm-svn: 319967
Summary:
NetBSD renames symbols for historical and compat reasons.
Add required symbol renames in sanitizer_common_interceptors.inc:
- gettimeofday -> __gettimeofday50
- getrusage -> __getrusage50
- shmctl -> __shmctl50
Additionally handle sigaction symbol mangling.
Rename the function symbol in the file to SIGACTION_SYMNAME and define
it as __sigaction14 for NetBSD and sigaction for !NetBSD. We cannot use
simple renaming with the proprocessor, as there are valid fields named
sigaction and they must be left intact.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, vitalybuka, dvyukov
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40766
llvm-svn: 319966
Summary:
We want to automatically copy the appropriate mailing list
as well as #sanitizers for review requests to the compiler-rt repository.
For context, see the proposal and discussion here:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056032.html
Similar to D40179, I set up a new Diffusion repository with callsign
"CRT" for compiler-rt:
https://reviews.llvm.org/source/compiler-rt/
This explicitly updates compiler-rt's .arcconfig to point to the new
CRT repository in Diffusion, which will let us use Herald rules H270
and H271.
Reviewers: krytarowski, joerg, dvyukov, vitalybuka, sammccall
Reviewed By: sammccall
Subscribers: dlj, bkramer, dberris, llvm-commits, sammccall, klimek, #sanitizers
Differential Revision: https://reviews.llvm.org/D40498
llvm-svn: 319954
Summary:
Switching the rest of intercepted allocs to InternalAlloc (well, except
__libc_memalign) when current thread is 'in_symbolizer'. Symbolizer
might (and does) use allocation functions other than malloc/calloc/realloc.
posix_memalign is the one actually used, others switched just in case
(since the failure is obscure and not obvious to diagnose).
Reviewers: dvyukov
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D40877
llvm-svn: 319929
Summary:
Unlike the rest of the sanitizer code, lib/interception uses native macros like __linux__
to check for specific targets instead of the common ones like SANITIZER_LINUX.
When working on the Solaris port of the sanitizers, the current style was found to not
only be inconsistent, but clumsy to use because the canonical way to check for Solaris
is to check for __sun__ && __svr4__ which is a mouthful.
Therefore, this patch switches to use SANITIZER_* macros instead.
Tested on x86_64-pc-linux-gnu.
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: #sanitizers, srhines, krytarowski, llvm-commits, fedor.sergeev
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39798
llvm-svn: 319906
Summary:
This wasn't noticed: `RoundUpTo` doesn't produce a constant expression, so the
sizes were not constant either. Enforce them to be static const, replace
`RoundUpTo` by its expression. The compiler can now optimize the associated
computations accordingly.
Also looking at the produced assembly, `PageSize` was fetched multiple times
during `Allocate`, so keep a local value of it. As a result it's fetched once
and kept in a register.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40862
llvm-svn: 319903
r319165 introduced a change to CMakeLists.txt for xray where the set of supported
architectures for XRay was iterated over, tested if they could be targeted then
passed to add_compiler_rt_object_libraries. However all targets were passed,
rather than the architecture that was just tested. For cases such as MIPS, where
mips and mips64 are supported, cmake would then test if mips64 could be targetted
resulting in an attempt to produce multiple identical logical target names, falling
afowl of CMP0002.
Reviewers: dberris
Differential Revision: https://reviews.llvm.org/D40890
llvm-svn: 319893
Summary:
NetBSD uses indirection symbol for a set of threading functions.
Add alias to handle __libc_thr_keycreate the same way as pthread_key_create.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, eugenis, vitalybuka
Reviewed By: vitalybuka
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40767
llvm-svn: 319868
Summary:
It was deemed that the salt in the chunk header didn't improve security
significantly (and could actually decrease it). The initial idea was that the
same chunk would different headers on different allocations, allowing for less
predictability. The issue is that gathering the same chunk header with different
salts can give information about the other "secrets" (cookie, pointer), and that
if an attacker leaks a header, they can reuse it anyway for that same chunk
anyway since we don't enforce the salt value.
So we get rid of the salt in the header. This means we also get rid of the
thread local Prng, and that we don't need a global Prng anymore as well. This
makes everything faster.
We reuse those 8 bits to store the `ClassId` of a chunk now (0 for a secondary
based allocation). This way, we get some additional speed gains:
- `ClassId` is computed outside of the locked block;
- `getActuallyAllocatedSize` doesn't need the `GetSizeClass` call;
- same for `deallocatePrimary`;
We add a sanity check at init for this new field (all sanity checks are moved
in their own function, `init` was getting crowded).
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40796
llvm-svn: 319791
Summary:
This change implements the basic mode filtering similar to what we do in
FDR mode. The implementation is slightly simpler in basic-mode filtering
because we have less details to remember, but the idea is the same. At a
high level, we do the following to decide when to filter function call
records:
- We maintain a per-thread "shadow stack" which keeps track of the
XRay instrumented functions we've encountered in a thread's
execution.
- We push an entry onto the stack when we enter an XRay instrumented
function, and note the CPU, TSC, and type of entry (whether we have
payload or not when entering).
- When we encounter an exit event, we determine whether the function
being exited is the same function we've entered recently, was
executing in the same CPU, and the delta of the recent TSC and the
recorded TSC at the top of the stack is less than the equivalent
amount of microseconds we're configured to ignore -- then we un-wind
the record offset an appropriate number of times (so we can
overwrite the records later).
We also support limiting the stack depth of the recorded functions,
so that we don't arbitrarily write deep function call stacks.
Reviewers: eizan, pelikan, kpw, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40828
llvm-svn: 319762
Summary:
This change allows for registration of multiple logging implementations
through a central mechanism in XRay, mapping an implementation to a
"mode". Modes are strings that are used as keys to determine which
implementation to install through a single API. This mechanism allows
users to choose which implementation to install either from the
environment variable 'XRAY_OPTIONS' with the `xray_mode=` flag, or
programmatically using the `__xray_select_mode(...)` function.
Here, we introduce two API functions for the XRay logging:
__xray_log_register_mode(Mode, Impl): Associates an XRayLogImpl to a
string Mode. We can only have one implementation associated with a given
Mode.
__xray_log_select_mode(Mode): Finds the associated Impl for Mode and
installs it as if by calling `__xray_set_log_impl(...)`.
Along with these changes, we also deprecate the xray_naive_log and
xray_fdr_log flags and encourage users to instead use the xray_mode
flag.
Reviewers: kpw, dblaikie, eizan, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40703
llvm-svn: 319759
Summary:
To be more portable (especially w.r.t. platforms without system()),
commands should be managed programmatically rather than via string
manipulation on the command line. This change introduces
Fuzzer::Command, with methods to manage arguments and flags, set output
options, and execute the command.
Patch By: aarongreen
Reviewers: kcc, morehouse
Reviewed By: kcc, morehouse
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D40103
llvm-svn: 319680
Summary:
This is an attempt at making `PopulateFreeArray` less obscure, more consistent,
and a tiny bit faster in some circumstances:
- use more consistent variable names, that work both for the user & the metadata
portions of the code; the purpose of the code is mostly the same for both
regions, so it makes sense that the code should be mostly similar as well;
- replace the while sum loops with a single `RoundUpTo`;
- mask most of the metadata computations behind kMetadataSize, allowing some
blocks to be completely optimized out if not use metadata;
- `const` the constant variables;
- add a `LIKELY` as the branch it applies to will almost always be taken.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D40754
llvm-svn: 319673
Following patch adds support of all memory origins in
CheckForInvalidPointerPair function. For small difference of pointers,
it's directly done in shadow memory (the limit was set to 2048B).
Then we search for origin of first pointer and verify that the second
one has the same origin. If so, we verify that it points either to a same
variable (in case of stack memory or a global variable), or to a same
heap segment.
Committing on behanf of marxin and jakubjelinek.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits
Differential revision: https://reviews.llvm.org/D40600
llvm-svn: 319668
Summary:
The low-fat STL-like vector container will be reused in MSan.
It is needed to implement an atexit(3) interceptor on NetBSD/amd64 in MSan.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, eugenis, vitalybuka, kcc
Reviewed By: dvyukov
Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40726
llvm-svn: 319650
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319575
Per beanz, building compiler-rt standalone is a pretty important use
case, so the comment is very out of date.
Differential Revision: https://reviews.llvm.org/D40740
llvm-svn: 319570
These targets strip during installation, and are required to support
install-distribution-stripped in LLVM (to support a stripped
distribution). LLVM has an add_llvm_install_targets function for this
purpose, but we can't rely on LLVM being present.
Differential Revision: https://reviews.llvm.org/D40687
llvm-svn: 319569
This reverts commit r319525.
This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio
llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
if root.host_os not in ['Linux'] or not is_gold_linker_available():
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
stderr = subprocess.PIPE)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
llvm-svn: 319529
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319525
Now that we have disabled the run-forever tests, and cleaned up the
intel 80-bit float based tests, we should be able to enable testing
compiler-rt for powerpc64.
llvm-svn: 319474
Summary:
Currently sys/cachectl.h is used unconditionally on MIPS although it is
only available on Linux and will fail the build when targeting baremetal
Reviewers: petarj
Reviewed By: petarj
Subscribers: sdardis, krytarowski
Differential Revision: https://reviews.llvm.org/D40659
llvm-svn: 319455
Summary:
In cases where we can't use the .preinit_array section (as in Darwin for
example) we instead use dynamic initialisation. We know that this
alternative approach will race with the initializers of other objects at
global scope, but this is strictly better than nothing.
Reviewers: kubamracek, nglevin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40599
llvm-svn: 319366
On macOS, we usually don't require launching the target with DYLD_INSERT_LIBRARIES anymore. However, it is still necessary when running a target that is not instrumented (and e.g. dlopen's an instrument library later). In any case, ASan and TSan currently remove themselves from the DYLD_INSERT_LIBRARIES environment variable to avoid passing it onto children. This works well e.g. when instrumenting a shell. A problem arises when the target is a non-instrumented shim (e.g. "xcrun") that either re-execs or launches a child that is supposed to get DYLD_INSERT_LIBRARIES propagated. To support this mode, this patch introduces 'strip_env' flag that can be used to keep DYLD_INSERT_LIBRARIES untouched.
Differential Revision: https://reviews.llvm.org/D39991
llvm-svn: 319365
Summary:
With this change, we allow someone to chose the `SizeClassMap` they want to use
at compile time via a define.
I feel somewhat unimaginative with the name of the defines, so if someone has a
better idea, let me know. I have been alternating between those and
`SCUDO_USE_xxx_SIZECLASSMAP` which is clearer but also longer. The issue with
those is that it wouldn't be consistent with `SCUDO_TSD_EXCLUSIVE` that should
probably become `SCUDO_USE_EXCLUSIVE_TSD` maybe?
Anyway, naming is hard, and I am not sure what makes more sense!
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D40521
llvm-svn: 319350
It looks FindDynamicShadowStart has a bug: When iterating over the memory map, we will not consider the very last gap in the address space. Let's fix that.
Differential Revision: https://reviews.llvm.org/D39989
llvm-svn: 319348
It's explicitly forbidden to call fclose with NULL, but at least on Darwin, this succeeds and doesn't segfault. To maintain binary compatibility, ASan should survice fclose(NULL) as well.
Differential Revision: https://reviews.llvm.org/D40053
llvm-svn: 319347
Calling getpwnam(NULL) is probably a bug, but at least on Darwin, such a call succeeds without segfaulting. I have some existing code that relies on that. To maintain binary compatibility, ASan should also survive a call to getpwnam with NULL.
Differential Revision: https://reviews.llvm.org/D40052
llvm-svn: 319344
This renames ASM_TSAN_SYMBOL and ASM_TSAN_SYMBOL_INTERCEPTOR to just ASM_SYMBOL and ASM_SYMBOL_INTERCEPTOR, because they can be useful in more places than just TSan. Also introduce a CMake function to add ASM sources to a target.
Differential Revision: https://reviews.llvm.org/D40143
llvm-svn: 319339
rL319241 was a bit too aggressive removing sources dependencies. This
restores the actual required dependency for armhf.
Follow-up to D39114.
llvm-svn: 319255
This isolates the per-architecture files from the common files
implementing the XRay facilities. Because of the refactoring done in
D39114, we were including the definition of the sources in the archive
twice, causing link-time failures.
Follow-up to D39114.
llvm-svn: 319241
Summary:
Load process memory map after updating the same cache to reflect the
umap happening in the process of updating.
Also clear out the buffer in case of failed read of /proc/self/maps (not
the source of stale segments, but can lead to the similar crash).
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D40529
llvm-svn: 319237
This is based on discussion in https://reviews.llvm.org/D40376 .
The comments try to explain the reason for the current implementation
and note that it might change in the future, so clients should not
rely on this particular implementation.
Differential Revision: https://reviews.llvm.org/D40565
llvm-svn: 319190
Summary:
This change adds support for the setjmp(3)/longjmp(3)
family of functions on NetBSD.
There are three types of them on NetBSD:
- setjmp(3) / longjmp(3)
- sigsetjmp(3) / sigsetjmp(3)
- _setjmp(3) / _longjmp(3)
Due to historical and compat reasons the symbol
names are mangled:
- setjmp -> __setjmp14
- longjmp -> __longjmp14
- sigsetjmp -> __sigsetjmp14
- siglongjmp -> __siglongjmp14
- _setjmp -> _setjmp
- _longjmp -> _longjmp
This leads to symbol renaming in the existing codebase.
There is no such symbol as __sigsetjmp/__longsetjmp
on NetBSD
Add a comment that GNU-style executable stack
note is not needed on NetBSD. The stack is not
executable without it.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, vitalybuka
Reviewed By: dvyukov
Subscribers: llvm-commits, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40337
llvm-svn: 319189
Vitaly Buka