Summary:
sysconf(_SC_PAGESIZE) is called very early, during sanitizer init and
any instrumented code (a wrapper/interceptor will likely be instrumented)
calling back to sanitizer before init is done will most surely crash.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31092
llvm-svn: 298305
check for the existence of RTLD_DEEPBIND, since this constant is only
supported for glibc >= 2.3.4. This fixes builds for FreeBSD and other
platforms that do not have RTLD_DEEPBIND.
llvm-svn: 297763
Summary: This is useful in some platforms where one of these signals is special.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30783
llvm-svn: 297665
People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see https://github.com/google/sanitizers/issues/611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.
Differential Revision: https://reviews.llvm.org/D30504
llvm-svn: 297370
There are two possible return values for strerror_r:
On OS X, the return value is always `int`.
On Linux, the return value can be either `char *` or `int`, depending
on the value of:
`(_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE`
Because OS X interceptors require a matching function signature,
split out the two cases into separate interceptors, using the above
information to determine the correct signature for a given build.
llvm-svn: 297315
Summary:
If symbolizer was instrumented with sanitizer and crash, it may
try to call itself again causing infinite recursion of crashing processes.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D30222
llvm-svn: 295771
Summary:
The DLL thunks are stubs added to an instrumented DLL to redirect ASAN API calls
to the real ones in the main executable. These thunks must contain dummy
code before __asan_init got called. Unfortunately, MSVC linker is doing ICF and is
merging functions with the same body.
In our case, this two ASAN thunks were incorrectly merged:
```
asan_interface.inc:16
INTERFACE_FUNCTION(__asan_before_dynamic_init)
```
```
sanitizer_common_interface.inc:16
INTERFACE_FUNCTION(__sanitizer_verify_contiguous_container)
```
The same thunk got patched twice. After the second patching, calls to
`__asan_before_dynamic_init` are redirected to `__sanitizer_verify_contiguous_container`
and trigger a DCHECK on incorrect operands/
The problem was caused by the macro that is only using __LINE__ to prevent
collapsing code.
```
#define INTERCEPT_SANITIZER_FUNCTION(name)
extern "C" __declspec(noinline) void name() {
volatile int prevent_icf = (__LINE__ << 8); (void)prevent_icf;
```
The current patch is adding __COUNTER__ which is safer than __LINE__.
Also, to precent ICF (guarantee that code is different), we are using a unique attribute:
- the name of the function
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D30219
llvm-svn: 295761
Summary:
Coverage is using large arrays which requires large allocations.
These allocations are flaky and often failing on win64.
We are using the 32-bits size until this gets a better fix.
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D29945
llvm-svn: 295086
Summary:
This patch provides stubs for all of the lsan platform-specific
functions which need to be implemented for darwin. Currently
all of these functions are stubs, for the purpose of fixing
compilation.
Reviewers: kcc, glider, kubamracek
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29784
llvm-svn: 294983
Summary:
Since struct rtentry is an internal kernel-only structure on FreeBSD,
and SIOCADDRT and SIOCDELRT are not supported anyway, stop including
socketvar.h and attempting to get at the definition of struct rtentry,
and move the line with struct_rtentry_sz to the SANIZER_LINUX block.
Reviewers: kcc, kutuzov.viktor.84, emaste
Reviewed By: kcc, emaste
Subscribers: emaste, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D29832
llvm-svn: 294806
Summary: This patch adds whitelist for RHEL6 and RHEL7 kernels that are known to have the CVE fixed.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29825
llvm-svn: 294799
Summary:
GET_CALLER_PC doesn't work properly on 31-bit s390, as pointers are 31-bit, the MSB bit can be set when the return address is copied into integer.
This causes e.g. errors like:
#0 0xfdadb129 (<unknown module>)
#1 0x7da5e1d1 in __asan::GetStackTraceWithPcBpAndContext(__sanitizer::BufferedStackTrace*, unsigned long, unsigned long, unsigned long, void*, bool) ../../../../../libsanitizer/asan/asan_stack.h:50
#2 0x7da5e1d1 in __asan::ErrorGeneric::Print() ../../../../../libsanitizer/asan/asan_errors.cc:482
#3 0x7db178d5 in __asan::ErrorDescription::Print() ../../../../../libsanitizer/asan/asan_errors.h:360
#4 0x7db178d5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() ../../../../../libsanitizer/asan/asan_report.cc:167
#5 0x7db178d5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ../../../../../libsanitizer/asan/asan_report.cc:397
#6 0x7dadb14f in __interceptor_memcmp ../../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626
#7 0x400cf5 in main /home/jakub/gcc/gcc/testsuite/c-c++-common/asan/memcmp-1.c:14
#8 0x7d807215 in __libc_start_main (/lib/libc.so.6+0x1a215)
#9 0x4007ed (/home/jakub/gcc/obj/gcc/testsuite/memcmp-1.exe+0x4007ed)
The actual return PC inside __interceptor_memcmp was 0x7dadb129 rather than 0xfdadb129.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29824
llvm-svn: 294793
Summary:
Symbol __tls_get_addr_internal is a GLIBC_PRIVATE private symbol on s390{,x}, the glibc folks aren't very happy about asan using it.
Additionally, only recent glibc versions have it, older versions just have __tls_get_offset and nothing else.
The patch doesn't drop the __tls_get_addr_internal interception altogether, but changes it so that it calls real __tls_get_offset function instead (and much more importantly,
that __tls_get_offset interception calls the real __tls_get_offset function).
This way it should work also on glibc 2.18 and earlier. See http://gcc.gnu.org/PR79341 for further details.
Reviewers: kcc, koriakin
Reviewed By: kcc, koriakin
Subscribers: kubamracek, mehdi_amini
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D29735
llvm-svn: 294790
Summary:
This patch unifies the behavior of BlockingMutex on linux and mac,
resolving problems that can arise when BlockingMutex is used in
code shared by the two platforms but has different behavior depending
on the platform.
No longer requires that the calling thread own the mutex for
CheckLocked calls to pass.
Reviewers: dvyukov, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29728
llvm-svn: 294614
When building for Windows, we would check if we were using MSVC rather
than WIN32. This resulted in needed targets not being defined by
sanitizer_common. Fix the conditional.
When registering the objects libraries for ASAN, we would multiply
register for all targets as we were creating them inside a loop over all
architectures. Only define the target per architecture.
llvm-svn: 294510
Summary: lib/sanitizer_common/sanitizer_win_defs.h defineds WINAPI, which is also defined by standard Windows headers. Redefining it causes warnings during compilation. This change causes us to only define WINAPI if it is not already defined, which avoids the warnings.
Reviewers: rnk, zturner, mpividori
Reviewed By: rnk, mpividori
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29683
llvm-svn: 294497
Add support for weak hooks on Windows, as we do on Linux and Darwin.
As we use the macro: `SANITIZER_INTERFACE_WEAK_DEF()` it was not necessary to
modify the header file: `sanitizer_common_interceptors.h`.
After this diff, many tests were fixed for libFuzzer.
Differential Revision: https://reviews.llvm.org/D29562
llvm-svn: 294409
On Windows, the symbols "___stop___sancov_guards" and "___start___sancov_guards"
are not defined automatically. So, we need to take a different approach.
We define 3 sections: ".SCOV$A", ".SCOV$M" and ".SCOV$Z".
Section ".SCOV$A" will only hold a variable ___start___sancov_guard.
Section ".SCOV$M" will hold the main data.
Section ".SCOV$Z" will only hold a variable ___stop___sancov_guards.
When linking, they will be merged sorted by the characters after the $, so we
can use the pointers of the variables ___[start|stop]___sancov_guard to know the
actual range of addresses of that section.
___[start|stop]___sancov_guard should be defined only once per module. On
Windows, we have 2 different cases:
+ When considering a shared runtime:
All the modules, main executable and dlls, are linked to an auxiliary static
library dynamic_runtime_thunk.lib. Because of that, we include the delimiters
in `SancovDynamicRuntimeThunk`.
+ When considering a static runtime:
The main executable in linked to the static runtime library.
All the dlls are linked to an auxiliary static library dll_thunk.
Because of that, we include the delimiter to both `SancovDllThunk` and
`SANITIZER_LIBCDEP_SOURCES` (which is included in the static runtime lib).
Differential Revision: https://reviews.llvm.org/D28435
llvm-svn: 293959
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
In Windows, when the sanitizer is implemented as a shared library (DLL), we need
an auxiliary static library dynamic_runtime_thunk that will be linked to the
main executable and dlls.
In the sanitizer DLL, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(),
which exports the default implementation with __dll suffix. For example: for
sanitizer coverage, the default implementation of __sanitizer_cov_trace_cmp is
exported as: __sanitizer_cov_trace_cmp__dll.
In the dynamic_runtime_thunk static library, we include weak aliases to the
imported implementation from the dll, using the macro WIN_WEAK_IMPORT_DEF().
By default, all users's programs that include calls to weak functions like
__sanitizer_cov_trace_cmp, will be redirected to the implementation in the dll,
when linking to dynamic_runtime_thunk.
After this diff, we are able to compile code with sanitizer coverage
instrumentation on Windows. When the instrumented object files are linked with
clang-rt_asan_dynamic_runtime_thunk-arch.lib all the weak symbols will be
resolved to the implementation imported from asan dll.
All the files sanitizer_dynamic_runtime_thunk.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we compile: [asan|ubsan|sanitizer_coverage]_win_dynamic_runtime_thunk.cc
and sanitizer_win_dynamic_runtime_thunk.cc to generate
asan_dynamic_runtime_thunk.lib, because we include asan, ubsan and sanitizer
coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29158
llvm-svn: 293953
In this diff, I update current implementation of the interception in dll_thunks
to consider the special case of weak functions.
First we check if the client has redefined the function in the main executable
(for example: __sanitizer_cov_trace_pc_guard). It we can't find it, then we look
for the default implementation (__sanitizer_cov_trace_pc_guard__dll). The
default implementation is always available because the static runtime is linked
to the main executable.
Differential Revision: https://reviews.llvm.org/D29155
llvm-svn: 293952
When the sanitizer is implemented as a static library and is included in the
main executable, we need an auxiliary static library dll_thunk that will be
linked to the dlls that have instrumentation, so they can refer to the runtime
in the main executable. Basically, it uses interception to get a pointer the
function in the main executable and override its function with that pointer.
Before this diff, all of the implementation for dll_thunks was included in asan.
In this diff I split it into different sanitizers, so we can use other
sanitizers regardless of whether we include asan or not.
All the sanitizers include a file sanitizer_win_dll_thunk.cc that register
functions to be intercepted in the binary section: DLLTH
When the dll including dll_thunk is initialized, it will execute
__dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc,
which will consider all the CB registered in the section DLLTH. So, all the
functions registered will be intercepted, and redirected to the implementation
in the main executable.
All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to
include a specific list of sanitizers. Now, we compile: asan_win_dll_thunk.cc
ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and
sanitizer_win_dll_thunk.cc, to generate asan_dll_thunk, because we include asan,
ubsan and sanitizer coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29154
llvm-svn: 293951
When dealing with GCD worker threads, TSan currently prints weird things like "created by thread T-1" and "[failed to restore the stack]" in reports. This patch avoids that and instead prints "Thread T3 (...) is a GCD worker thread".
Differential Revision: https://reviews.llvm.org/D29103
llvm-svn: 293882
After this commint, we can include sancov_flags.h and refer to
__sancov_default_options without requiring the namespace prefix.
Differential Revision: https://reviews.llvm.org/D29167
llvm-svn: 293731
Add a new auxiliary file to each sanitizer: sanitizer_interface.inc, listing all
the functions exported, with the macros: INTERFACE_FUNCTION() and
INTERFACE_WEAK_FUNCTION().
So, when we need to define or repeat a procedure for each function in the
sanitizer's interface, we can define the macros and include that header.
In particular, these files are needed for Windows, in the nexts commits.
Also, this files could replace the existing files: weak_symbols.txt for Apple.
Instead of reading weak_symbols.txt to get the list of weak symbols, we could
read the file sanitizer_interface.inc and consider all the symbols included with
the macro INTERFACE_WEAK_FUNCTION(Name).
In this commit, I only include these files to the sanitizers that work on
Windows. We could do the same for the rest of the sanitizers when needed.
I updated tests for: Linux, Darwin and Windows. If a new function is exported
but is not present in the interface list, the tests
"interface_symbols_[darwin|windows|linux].c" fail.
Also, I remove the comments: "/* OPTIONAL */" which are not required any more,
because we use the macro: INTERFACE_WEAK_FUNCTION() for weak functions.
Differential Revision: https://reviews.llvm.org/D29148
llvm-svn: 293682
Summary:
g_tls_size is not supposed to be changed after initialization. It's not
atomic, not guarded by a lock, nor thread_local. But it's read by
multiple threads.
The reason why it's mutated is mips and powerpc64 specific. We can
implement the same funcitonality without mutating g_tls_size.
I'm not sure how to write a test for this. Please advice. Thanks!
Reviewers: eugenis, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D29236
llvm-svn: 293586
macOS
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Also delete the non-functional `cfree` wrapper for Windows, to fix the
test cases on that platform.
Reviewers: emaste, kcc, rnk
Subscribers: timurrrr, eugenis, hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
llvm-svn: 293536
Update the headers, so we can change the dllexports to dllimport when
defining SANITIZER_IMPORT_INTERFACE.
Differential Revision: https://reviews.llvm.org/D29052
llvm-svn: 293422
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
This reverts r293337, which breaks tests on Windows:
malloc-no-intercept-499eb7.o : error LNK2019: unresolved external symbol _mallinfo referenced in function _main
llvm-svn: 293346
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Reviewers: emaste, kcc
Subscribers: hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
llvm-svn: 293337
pc_array_size and kPcArrayMaxSize appear to be measured in elements, not
bytes, so we shouldn't multiply idx by sizeof(uptr) in this bounds
check. 32-bit Chrome was tripping this assertion because it has 64
million coverage points. I don't think it's worth adding a test that has
that many coverage points.
llvm-svn: 292955
Breaks tests on i686/Linux due to missing clang driver support:
error: unsupported option '-fsanitize=leak' for target 'i386-unknown-linux-gnu'
llvm-svn: 292844
People keep asking LSan to be available on 32 bit targets (e.g. https://github.com/google/sanitizers/issues/403)
despite the fact that false negative ratio might be huge (up to 85%). This happens for big real world applications
that may contain random binary data (e.g. browser), but for smaller apps situation is not so terrible and LSan still might be useful.
This patch adds initial support for x86 Linux (disabled by default), ARM32 is in TODO list.
We used this patch (well, ported to GCC) on our 32 bit mobile emulators and it worked pretty fine
thus I'm posting it here to initiate further discussion.
Differential Revision: https://reviews.llvm.org/D28609
llvm-svn: 292775
This patch adds some useful macros for dealing with pragma directives on
Windows. Also, I add appropriate documentation for future users.
Differential Revision: https://reviews.llvm.org/D28525
llvm-svn: 292650
Summary:
There are cases when thread local quarantine drains almost empty
quarantine batches into the global quarantine. The current approach leaves
them almost empty, which might create a huge memory overhead (each batch
is 4K/8K, depends on bitness).
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28068
llvm-svn: 292525
Summary:
Bypass quarantine altogether when quarantine size is set ot zero.
Also, relax atomic load/store of quarantine parameters, the
release/acquire semantics is an overkill here.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D28586
llvm-svn: 291791
On Darwin, we currently use 'ignore_interceptors_accesses', which is a heavy-weight solution that simply turns of race detection in all interceptors. This was done to suppress false positives coming from system libraries (non-instrumented code), but it also silences a lot of real races. This patch implements an alternative approach that should allow us to enable interceptors and report races coming from them, but only if they are called directly from instrumented code.
The patch matches the caller PC in each interceptors. For non-instrumented code, we call ThreadIgnoreBegin.
The assumption here is that the number of instrumented modules is low. Most likely there's only one (the instrumented main executable) and all the other modules are system libraries (non-instrumented).
Differential Revision: https://reviews.llvm.org/D28264
llvm-svn: 291631
Revert "ASAN activate/deactive controls thread_local_quarantine_size_kb option."
Revert "Bypass quarantine when quarantine size is set ot zero."
Revert "ASAN activate/deactive controls thread_local_quarantine_size_kb option."
One of these commits broke some of the ARM / AArch64 buildbots:
TEST 'AddressSanitizer-aarch64-linux :: TestCases/Posix/start-deactivated.cc' FAILED
Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-aarch64-42vma/llvm/projects/compiler-rt/test/asan/TestCases/Posix/start-deactivated.cc:85:12: error: expected string not found in input
// CHECK: WARNING: AddressSanitizer failed to allocate 0xfff{{.*}} bytes
^
<stdin>:1:1: note: scanning from here
start-deactivated.cc.tmp: /home/buildslave/buildslave/clang-cmake-aarch64-42vma/llvm/projects/compiler-rt/test/asan/TestCases/Posix/start-deactivated.cc:40: void test_malloc_shadow(char *, size_t, bool): Assertion `(char *)__asan_region_is_poisoned(p - 1, sz + 1) == (expect_redzones ? p - 1 : nullptr)' failed.
^
<stdin>:2:1: note: possible intended match here
Error: Aborted (core dumped)
^
llvm-svn: 291560
Summary:
The build system was inconsistent in its naming conventions for
link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS,
for consistency with cmake's LINK_FLAGS property.
This patch should make it easier to search the source code for
uses of link flags, as well as providing the benefit of improved
style and consistency.
Reviewers: compnerd, beanz
Subscribers: kubabrecka, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28506
llvm-svn: 291539
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291417
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291314
This patch starts passing architecture information about a module to llvm-symbolizer and into text reports. This fixes the longstanding x86_64/x86_64h mismatch issue on Darwin.
Differential Revision: https://reviews.llvm.org/D27390
llvm-svn: 291287
This patch add a new sanitizer flag, print_module_map, which enables printing a module map when the process exits, or after each report (for TSan). The output format is very similar to what Crash Reporter produces on Darwin (e.g. the format of module UUIDs). This enables users to use the existing symbol servers to offline symbolicate and aggregate reports.
Differential Revision: https://reviews.llvm.org/D27400
llvm-svn: 291277
This patch adds tracking which modules are instrumented and which are not. On macOS, instrumented modules link against the ASan/TSan/... dylib, so we can just check if such a load command exists or not.
Differential Revision: https://reviews.llvm.org/D28263
llvm-svn: 291268
Summary:
Debug builds can have larger distance between stack trace and PC on that stack.
If we assume that PC is always correct we can snap it to the nearest trace.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D28342
llvm-svn: 291173
Summary:
At this point SANCOV_OPTIONS are not functional but it is our intent
to move here sanitizer coverage flags from various sanitizers _OPTIONS.
Reviewers: kcc
Subscribers: kubabrecka, mgorny
Differential Revision: https://reviews.llvm.org/D28311
llvm-svn: 291068
Summary:
A previous fix used __assume(0), but not all compilers know that control will
not pass that. This patch uses a macro which works in more compilers.
Reviewers: rnk
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D28268
llvm-svn: 291042
This allows compiler-rt to be built on older macOS SDKs, where there symbols are not defined.
Patch by Jeremy Huddleston Sequoia <jeremyhu@apple.com>.
llvm-svn: 290521
Summary: We setup these interceptors twice which hangs test on windows.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D28070
llvm-svn: 290393
Summary: Make thread local quarantine size an option so it can be turned off to save memory.
Reviewers: eugenis
Patch by Alex Shlyapnikov.
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28027
llvm-svn: 290373
Summary:
After rL289878/rL289881, the build on FreeBSD is broken, because
sanitizer_platform_limits_posix.cc attempts to include <utmp.h> and use
`struct utmp`, neither of which are supported anymore on FreeBSD.
Fix this by adding `&& !SANITIZER_FREEBSD` in a few places, and stop
intercepting utmp functions altogether for FreeBSD.
Reviewers: kubabrecka, emaste, eugenis, ed
Subscribers: ed, llvm-commits
Differential Revision: https://reviews.llvm.org/D27902
llvm-svn: 290167
Summary:
I atually had an integer overflow on 32-bit with D27428 that didn't reproduce
locally, as the test servers would manage allocate addresses in the 0xffffxxxx
range, which led to some issues when rounding addresses.
At this point, I feel that Scudo could benefit from having its own combined
allocator, as we don't get any benefit from the current one, but have to work
around some hurdles (alignment checks, rounding up that is no longer needed,
extraneous code).
Reviewers: kcc, alekseyshl
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D27681
llvm-svn: 289572
In certain OS versions, it was possible that libmalloc replaced the sanitizer zone from being the default zone (i.e. being in malloc_zones[0]). This patch introduces a failsafe that makes sure we always stay the default zone. No testcase for this, because this doesn't reproduce under normal circumstances.
Differential Revision: https://reviews.llvm.org/D27083
llvm-svn: 289376
We currently have a interceptor for malloc_create_zone, which returns a new zone that redirects all the zone requests to our sanitizer zone. However, calling malloc_destroy_zone on that zone will cause libmalloc to print out some warning messages, because the zone is not registered in the list of zones. This patch handles this and adds a testcase for that.
Differential Revision: https://reviews.llvm.org/D27083
llvm-svn: 289375
Summary: I see crashes on this check when some reports are being generated.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D27574
llvm-svn: 289145
Summary:
The combined allocator rounds up the requested size with regard to the
alignment, which makes sense when being serviced by the primary as it comes
with alignment guarantees, but not with the secondary. For the rare case of
large alignments, it wastes memory, and entices unnecessarily large fields for
the Scudo header. With this patch, we pass the non-alignement-rounded-up size
to the secondary, and adapt the Scudo code for this change.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D27428
llvm-svn: 289088
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
TSan runtime shouldn't contain memset, so internal_memset is used
instead and syntax that emits memset is avoided.
This doesn't fail in-tree due to TSan being build with -03, but it fails
when TSan is built with -O0, and is (I think) a true positive.
Patch by Sam McCall, review: https://reviews.llvm.org/D27407
llvm-svn: 288672
On macOS, we often symbolicate using atos (when llvm-symbolizer is not found). The current way we invoke atos involves creating a pseudo-terminal to make sure atos doesn't buffer its output. This however also makes atos think that it's stdin is interactive and in some error situations it will ask the user to enter some input instead of just printing out an error message. For example, when Developer Mode isn't enabled on a machine, atos cannot examine processes, and it will ask the user to enter an administrator's password, which will make the sanitized process get stuck. This patch only connects the pseudo-terminal to the stdout of atos, and uses a regular pipe as its stdin.
Differential Revision: https://reviews.llvm.org/D27239
llvm-svn: 288624
When we enumerate loaded modules, we only track the module name and base address, which then has several problems on macOS. Dylibs and executables often have several architecture slices and not storing which architecture/UUID is actually loaded creates problems with symbolication: A file path + offset isn't enough to correctly symbolicate, since the offset can be valid in multiple slices. This is especially common for Haswell+ X86_64 machines, where x86_64h slices are preferred, but if one is not available, a regular x86_64 is loaded instead. But the same issue exists for i386 vs. x86_64 as well.
This patch adds tracking of arch and UUID for each LoadedModule. At this point, this information isn't used in reports, but this is the first step. The goal is to correctly identify which slice is loaded in symbolication, and also to output this information in reports so that we can tell which exact slices were loaded in post-mortem analysis.
Differential Revision: https://reviews.llvm.org/D26632
llvm-svn: 288537
Summary:
The current code was sometimes attempting to release huge chunks of
memory due to undesired RoundUp/RoundDown interaction when the requested
range is fully contained within one memory page.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Patch by Aleksey Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D27228
llvm-svn: 288271
Summary:
In order to avoid starting a separate thread to return unused memory to
the system (the thread interferes with process startup on Android,
Zygota waits for all threads to exit before fork, but this thread never
exits), try to return it right after free.
Reviewers: eugenis
Subscribers: cryptoad, filcab, danalbert, kubabrecka, llvm-commits
Patch by Aleksey Shlyapnikov.
Differential Revision: https://reviews.llvm.org/D27003
llvm-svn: 288091
See D19555 for rationale. As it turns out, this treatment is also necessary
for scanf/printf.
Differential Revision: https://reviews.llvm.org/D27118
llvm-svn: 288064
Handling SIGILL on Darwin works fine, so let's just make this feature work and re-enable the ill.cc testcase.
Differential Revision: https://reviews.llvm.org/D27141
llvm-svn: 287959
This patch prints out all CPU registers after a SIGSEGV. These are available in the signal handler context. Only implemented for Darwin. Can be turned off with the dump_registers flag.
Differential Revision: https://reviews.llvm.org/D11365
llvm-svn: 287957
/proc/self/maps can't be read atomically, this leads to episodic
crashes in libignore as it thinks that a module is loaded twice.
See the new test for an example.
dl_iterate_phdr does not have this problem.
Switch libignore to dl_iterate_phdr.
llvm-svn: 287632
Summary: The new name better corresponds to its logic.
Reviewers: kcc
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D26821
llvm-svn: 287377
Summary:
ASan needs to initialize before ucrtbase.dll so that it can intercept
all of its heap allocations. New versions of dbghelp.dll depend on
ucrtbase.dll, which means both of those DLLs will initialize before the
dynamic ASan runtime. By lazily loading dbghelp.dll with LoadLibrary, we
avoid the issue.
Eventually, I would like to remove our dbghelp.dll dependency in favor
of always using llvm-symbolizer.exe, but this seems like an acceptable
interim solution.
Fixes PR30903
Reviewers: etienneb
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26473
llvm-svn: 286848
Summary:
In non-strict mode we will check memory access for both strings from beginning
to either:
1. 0-char
2. size
3. different chars
In strict mode we will check from beginning to either:
1. 0-char
2. size
Previously in strict mode we always checked up to the 0-char.
Reviewers: kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26574
llvm-svn: 286708
Now that we use TerminateProcess, the debugger doesn't stop on program
exit. Add this breakpoint so that the debugger stops after asan reports
an error and is prepared to exit the program.
llvm-svn: 286501
ExitProcess still runs some code which can lead to ASan interceptors
running after CHECK failure. This can lead to deadlock if it CHECK fails
again. Avoid that mess by really exiting immediately.
llvm-svn: 286395
Go maps shadow memory lazily, so we don't have the huge multi-TB mapping.
Virtual memory consumption is proportional to normal memory usage.
Also in Go core dumps are enabled explicitly with GOTRACEBACK=crash,
if user explicitly requests a core that must be on purpose.
So don't disable core dumps by default.
llvm-svn: 285451
Currently we either define SANITIZER_GO for Go or don't define it at all for C++.
This works fine with preprocessor (ifdef/ifndef/defined), but does not work
for C++ if statements (e.g. if (SANITIZER_GO) {...}). Also this is different
from majority of SANITIZER_FOO macros which are always defined to either 0 or 1.
Always define SANITIZER_GO to either 0 or 1.
This allows to use SANITIZER_GO in expressions and in flag default values.
Also remove kGoMode and kCppMode, which were meant to be used in expressions,
but they are not defined in sanitizer_common code, so SANITIZER_GO become prevalent.
Also convert some preprocessor checks to C++ if's or ternary expressions.
Majority of this change is done mechanically with:
sed "s#ifdef SANITIZER_GO#if SANITIZER_GO#g"
sed "s#ifndef SANITIZER_GO#if \!SANITIZER_GO#g"
sed "s#defined(SANITIZER_GO)#SANITIZER_GO#g"
llvm-svn: 285443
Looks like we are missing these flags only in tsan and sanitizer-common.
This results in linker warnings in some settings as it can cause the Unit
tests to be built with a different SDK version than that was used to build
the runtime. For example, we are not setting the minimal deployment target
on the tests but are setting the minimal deployment target for the sanitizer
library, which leads to the following warning on some bots: ld: warning:
object file (sanitizer_posix_test.cc.i386.o) was built for newer OSX version
(10.12) than being linked (10.11).
Differential Revision: https://reviews.llvm.org/D25860https://reviews.llvm.org/D25352
llvm-svn: 285255
Summary:
LeakSanitizer does not work with ptrace but currently it
will print warnings (only under verbosity=1) and then proceed
to print tons of false reports.
This patch makes lsan fail hard under ptrace with a verbose message.
https://github.com/google/sanitizers/issues/728
Reviewers: eugenis, vitalybuka, aizatsky
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D25538
llvm-svn: 284171
Used uptr for __sanitizer_kernel_sigset_t.sig to avoid byte order issues on big endian systems
Reviewd by bruening.
Differential: D24332
llvm-svn: 283438
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283375
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283240
Summary:
This patch is adding support for dynamic shadow allocation.
This is a merge and re-commit of the following patches.
```
[compiler-rt] Fix Asan build on Android
https://reviews.llvm.org/D24768
[compiler-rt] Add support for the dynamic shadow allocation
https://reviews.llvm.org/D23363
```
This patch needed to re-land at the same time:
```
[asan] Support dynamic shadow address instrumentation
https://reviews.llvm.org/D23354
```
Reviewers: rnk, zaks.anna
Subscribers: tberghammer, danalbert, kubabrecka, dberris, chrisha, llvm-commits
Differential Revision: https://reviews.llvm.org/D25104
llvm-svn: 282882
Summary:
This patch is adding the needed code to compiler-rt to support
dynamic shadow.
This is to support this patch:
https://reviews.llvm.org/D23354
It's adding support for using a shadow placed at a dynamic address determined
at runtime.
The dynamic shadow is required to work on windows 64-bits.
Reviewers: rnk, kcc, vitalybuka
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23363
llvm-svn: 281909
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
These got out of sync and the tests were failing for me locally. We
assume a 47 bit address space in ASan, so we should do the same in the
tests.
llvm-svn: 281622
Don't list __sanitizer_print_memory profile as an INTERFACE_FUNCTION. It
is not exported by ASan; it is exported by user code.
Move the weak definition from asan_win.cc to sanitizer_win.cc to fix the
ubsan tests.
llvm-svn: 281619
Summary: As mentioned in D24394, I'm moving tid to ErrorBase, since basically all errors need it.
Also mentioned in the same review are other cleanups like adding const
to BufferedStackTrace and make sure constructor orders are consistent.
Reviewers: vitalybuka, kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24455
llvm-svn: 281236
r280885 added a testcase for handle_abort, which is broken on macOS, let’s add this support into sanitizer_mac.cc.
Differential Revision: https://reviews.llvm.org/D24344
llvm-svn: 280945
Reset the SIGABRT signal handler before calling abort().
Also, change the error message when catching SIGABRT to say "ABRT"
instead of "SEGV".
llvm-svn: 280885
Normally, syslog() uses argv[0] for the log tag; bionic, however,
would crash in syslog() before libc constructor unless the log
tag is explicitly set with openlog().
llvm-svn: 280875
With this patch 10 out of 13 tests are passing.
Following is the list of failing tests:
struct-simple.cpp
workingset-signal-posix.cpp
mmap-shadow-conflict.c
Reviewed by bruening
Differential: D23799
llvm-svn: 280795
Clang added warning that taking the address of a packed struct member
possibly yields an unaligned pointer. This case is benign because
the pointer gets casted to an uptr and not used for unaligned accesses.
Add an intermediate cast to char* until this warning is improved (see
also https://reviews.llvm.org/D20561)
llvm-svn: 278835
With this change, the default behavior on error is to call abort()
instead of _exit(). This should help the OS to capture a tombstone of
the error.
RAM usage of the lit test suite goes up because of all the tombstone
gathering, so I'm limiting the parallelism of the test target.
Previously it was based on the number of the CPUs on the host
machine, which is definitely wrong.
llvm-svn: 278308
Summary:
While cross-compiling, a custom nm program may be required. This will also allow for the
use of llvm-nm if desired.
Reviewers: samsonov, beanz, compnerd, eugenis
Subscribers: kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D23278
llvm-svn: 278187
MSVC doesn't have an exact equivalent for __builtin_frame_address, but
_AddressOfReturnAddress() + sizeof(void*) should be equivalent for all
frames build with -fno-omit-frame-pointer.
llvm-svn: 277826
Summary:
The sanitizer allocators can works with a dynamic address space
(i.e. specified with ~0ULL).
Unfortunately, the code was broken on GetMetadata and GetChunkIdx.
The current patch is moving the Win64 memory test to a dynamic
address space. There is a migration to move every concept to a
dynamic address space on windows.
To have a better coverage, the unittest are now testing
dynamic address space on other platforms too.
Reviewers: rnk, kcc
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23170
llvm-svn: 277745
Summary:
Respect the handle_sigill common flag and handle_segv flags while we're
at it.
We still handle signals/exceptions differently on Unix and Windows. The
installation process is tricky on Windows, and difficult to push down
into sanitizer_common without concerning it with the different
static/dynamic CRT models on Windows.
Reviewers: kcc, etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23098
llvm-svn: 277621
In r235779, Timur bumped the buffer size up to 1<<27, or about 134
million coverage points, presumably to handle Chrome. We allocate two
arrays of uptrs with this size, and this reliably exhausts all available
address space on 32-bit Windows (2 allocations of 512MB) when ASan is
also enabled.
Let's reduce the buffer size for now to stabilize the test suite. We can
re-evaluate the approach later when we've brought the Chrome ASan
builders back to life.
Kostya said that Mike reduced the number of instrumented coverage points
that LLVM emits by half since Timur made this change, so reducing this
array size should also be safe.
With this change, the 32-bit ASan tests reliably pass for me on Windows
10.
llvm-svn: 277558
Summary:
Due to a QoI issuse in FreeBSD's libcxxrt-based demangler, one sanitizer
symbolizer test consistently appears to fail:
Value of: DemangleSwiftAndCXX("foo")
Actual: "float"
Expected: "foo"
This is because libcxxrt's __cxa_demangle() incorrectly demangles the "foo"
identifier to "float". It should return an error instead.
For now, XFAIL this particular test for FreeBSD, until we can fix libcxxrt
properly (which might take some time to coordinate with upstream).
Reviewers: rnk, zaks.anna, emaste
Subscribers: emaste, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23001
llvm-svn: 277297
Summary:
This patch is re-introducing the code to fix the
dynamic hooking on windows and to fix a compiler
warning on Apple.
Related patches:
* https://reviews.llvm.org/D22641
* https://reviews.llvm.org/D22610
* https://reviews.llvm.org/rL276311
* https://reviews.llvm.org/rL276490
Both architecture are using different techniques to
hook on library functions (memchr, strcpy,...).
On Apple, the function is not dynamically hooked and
the symbol always points to a valid function
(i.e. can't be null). The REAL macro returns the
symbol.
On windows, the function is dynamically patch and the
REAL(...) function may or may not be null. It depend
on whether or not the function was hooked correctly.
Also, on windows memcpy and memmove are the same.
```
#if !defined(__APPLE__)
[...]
# define REAL(x) __interception::PTR_TO_REAL(x)
# define ASSIGN_REAL(dst, src) REAL(dst) = REAL(src)
[...]
#else // __APPLE__
[...]
# define REAL(x) x
# define ASSIGN_REAL(x, y)
[...]
#endif // __APPLE__
Reviewers: rnk
Subscribers: kcc, hans, kubabrecka, llvm-commits, bruno, chrisha
Differential Revision: https://reviews.llvm.org/D22758
llvm-svn: 276885
The kernel on Nexus 5X returns error_code in ucontext which has
correct FSR_WRITE flag, but empty (zero) abort type field. Removing
the checks means that we will report all SEGVs as READ on very old
kernels, but will properly distinguish READ vs WRITE on moderately
old ones.
llvm-svn: 276803
This test attempts to allocate 100 512MB aligned pages of memory. This
is implemented in the usual way by allocating size + alignment bytes and
aligning the result. As a result, this test allocates 51.2GB of memory.
Windows allocates swap for all memory allocated, and our bots do not
have this much swap available.
Avoid the failure by using a more reasonable alignment, like 16MB, as we
do on 32-bit.
llvm-svn: 276779
sanitizer_common_interceptors.inc:667:12: warning: address of function 'memchr' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (REAL(memchr)) {
~~ ^~~~~~
llvm-svn: 276539
Add a %stdcxx11 lit substitution for -std=c++11. Windows defaults to
-std=c++14 when VS 2015 is used because the STL requires it. Harcoding
-std=c++11 in the ASan tests actually downgrades the C++ standard level,
leading to test failures.
Relax a FileCheck pattern in use-after-scope-types.cc.
Disable the sanitizer_common OOM tests. They fail on bots with low swap,
and cause other concurrently running tests to OOM.
llvm-svn: 276454
Vitaly Buka