Summary:
The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic,
but the tool interface will be general enough (or at least generalizable) to support any other libc.
When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions.
In fact, majority of interceptors become unnecessary when libc code is instrumented.
This change gets rid of most hwasan interceptors and provides interface for libc to notify
hwasan about thread creation and destruction events. Some interceptors (pthread_create)
are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in
terms of the new libc interface.
The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing
version of the library with the aforementioned pthread_create interceptor.
With the OFF setting, the library becomes more of a libc plugin.
Reviewers: vitalybuka, kcc, jfb
Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50922
llvm-svn: 340216
This reapplies commit r339935 with the following changes:
* make longjmp test C, not C++, to avoid dependency on libc++/libstdc++
* untag pointer in memset interceptor
x86_64 does not have TBI, so hwasan barely works there. Tests must be carefully
written in a way that does not leak tagged pointer to system libraries.
llvm-svn: 339963
Summary:
A callback to annotate longjmp-like code.
Unlike __asan_handle_no_return, in hwasan we can not conservatively
"unpoison" the entire thread stack, because there is no such thing as
unpoisoned memory. Pointer and memory tags must always match.
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50752
llvm-svn: 339935
Summary:
Export __sanitizer_malloc, etc as aliases to malloc, etc.
This way users can wrap sanitizer malloc, even in fully static binaries.
Both jemalloc and tcmalloc provide similar aliases (je_* and tc_*).
Reviewers: vitalybuka, kcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D50570
llvm-svn: 339614
Summary:
Provide __hwasan_shadow_init that can be used to initialize shadow w/o touching libc.
It can be used to bootstrap an unusual case of fully-static executable with
hwasan-instrumented libc, which needs to run hwasan code before it is ready to serve
user calls like madvise().
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D50581
llvm-svn: 339606
Summary:
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
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
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:
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:
`__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
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
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:
Purging allocator quarantine and returning memory to OS might be desired
between fuzzer iterations since, most likely, the quarantine is not
going to catch bugs in the code under fuzz, but reducing RSS might
significantly prolong the fuzzing session.
Reviewers: cryptoad
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D39153
llvm-svn: 316347
Add a new flag, __tsan_mutex_not_static, which has the opposite sense
of __tsan_mutex_linker_init. When the new __tsan_mutex_not_static flag
is passed to __tsan_mutex_destroy, tsan ignores the destruction unless
the mutex was also created with the __tsan_mutex_not_static flag.
This is useful for constructors that otherwise woud set
__tsan_mutex_linker_init but cannot, because they are declared constexpr.
Google has a custom mutex with two constructors, a "linker initialized"
constructor that relies on zero-initialization and sets
__tsan_mutex_linker_init, and a normal one which sets no tsan flags.
The "linker initialized" constructor is morally constexpr, but we can't
declare it constexpr because of the need to call into tsan as a side effect.
With this new flag, the normal c'tor can set __tsan_mutex_not_static,
the "linker initialized" constructor can rely on tsan's lazy initialization,
and __tsan_mutex_destroy can still handle both cases correctly.
Author: Greg Falcon (gfalcon)
Reviewed in: https://reviews.llvm.org/D39095
llvm-svn: 316209
It was pointed out that compiler-rt has always defined the symbol, but only
recently added it to the public headers. Meaning that libc++abi can re-declare
it instead of needing this macro.
llvm-svn: 313306
Summary:
Libc++abi attempts to use the newly added `__asan_handle_no_return()` when built under ASAN. Unfortunately older versions of compiler-rt do not provide this symbol, and so libc++abi needs a way to detect if `asan_interface.h` actually provides the function.
This patch adds the macro `SANITIZER_ASAN_INTERFACE_HAS_HANDLE_NO_RETURN` which can be used to detect the availability of the new function.
Reviewers: phosek, kcc, vitalybuka, alekseyshl
Reviewed By: phosek
Subscribers: mclow.lists, cfe-commits
Differential Revision: https://reviews.llvm.org/D37871
llvm-svn: 313303
Summary:
-dead_strip in ld64 strips weak interface symbols, which I believe
is most likely the cause of this test failure. Re-enable after marking the interface
function as used.
Reviewers: alekseyshl, kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37635
llvm-svn: 312824
Heretofore asan_handle_no_return was used only by interceptors,
i.e. code private to the ASan runtime. However, on systems without
interceptors, code like libc++abi is built with -fsanitize=address
itself and should call asan_handle_no_return directly from
__cxa_throw so that no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D36811
llvm-svn: 311869
This patch allows the Swift compiler to emit calls to `__tsan_external_write` before starting any modifying access, which will cause TSan to detect races on arrays, dictionaries and other classes defined in non-instrumented modules. Races on collections from the Swift standard library and user-defined structs and a frequent cause of subtle bugs and it's important that TSan detects those on top of existing LLVM IR instrumentation, which already detects races in direct memory accesses.
Differential Revision: https://reviews.llvm.org/D31630
llvm-svn: 302050
For a linker init mutex with lazy flag setup
(no __tsan_mutex_create call), it is possible that
no lock/unlock happened before the destroy call.
Then when destroy runs we still don't know that
it is a linker init mutex and will emulate a memory write.
This in turn can lead to false positives as the mutex
is in fact linker initialized.
Support linker init flag in destroy annotation to resolve this.
llvm-svn: 301795
There are several problems with the current annotations (AnnotateRWLockCreate and friends):
- they don't fully support deadlock detection (we need a hook _before_ mutex lock)
- they don't support insertion of random artificial delays to perturb execution (again we need a hook _before_ mutex lock)
- they don't support setting extended mutex attributes like read/write reentrancy (only "linker init" was bolted on)
- they don't support setting mutex attributes if a mutex don't have a "constructor" (e.g. static, Java, Go mutexes)
- they don't ignore synchronization inside of lock/unlock operations which leads to slowdown and false negatives
The new annotations solve of the above problems. See tsan_interface.h for the interface specification and comments.
Reviewed in https://reviews.llvm.org/D31093
llvm-svn: 298809
Summary: The function computes full module name and coverts pc into offset.
Reviewers: kcc
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D26820
llvm-svn: 288711
This patch extends __sanitizer_finish_switch_fiber method to optionally return previous stack base and size.
This solves the problem of coroutines/fibers library not knowing the original stack context from which the library is used. It's incorrect to assume that such context is always the default stack of current thread (e.g. one such library may be used from a fiber/coroutine created by another library). Bulding a separate stack tracking mechanism would not only duplicate AsanThread, but also require each coroutines/fibers library to integrate with it.
Author: Andrii Grynenko (andriigrynenko)
Reviewed in: https://reviews.llvm.org/D24628
llvm-svn: 282582
Adds a new esan public interface routine __esan_get_sample_count() and uses
it to ensure that tests of sampling receive the minimum number of samples.
llvm-svn: 275948
Summary:
Adds a new public interface routine __esan_report() which can be used to
request profiling results prior to abnormal termination (e.g., for a server
process killed by its parent where the normal exit does not allow for
normal result reporting).
Implements this for the working-set tool. The cache frag tool is left
unimplemented as it requires missing iteration capabilities.
Adds a new test.
Reviewers: aizatsky
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits, kubabrecka
Differential Revision: http://reviews.llvm.org/D22098
llvm-svn: 274964
This patch adds the __sanitizer_start_switch_fiber and
__sanitizer_finish_switch_fiber methods inspired from what can be found here
2ea64dd249 .
These methods are needed when the compiled software needs to implement
coroutines, fibers or the like. Without a way to annotate them, when the program
jumps to a stack that is not the thread stack, __asan_handle_no_return shows a
warning about that, and the fake stack mechanism may free fake frames that are
still in use.
Author: blastrock (Philippe Daouadi)
Reviewed in http://reviews.llvm.org/D20913
llvm-svn: 273260
