Summary:
We need one library to support all of 39, 42 and 48 bit VMAs, and
there is no common address that works for all of them.
Reviewers: kcc, alekseyshl, javed.absar
Subscribers: rengolin, srhines, kubamracek, kristof.beyls, llvm-commits, cryptoad
Differential Revision: https://reviews.llvm.org/D47160
llvm-svn: 333025
On RTEMS, system and user code all live in a single binary and address
space. There is no clean separation, and instrumented code may
execute before the ASan run-time is initialized (or after it has been
destroyed).
Currently, GetCurrentThread() may crash if it's called before ASan
run-time is initialized. Make it return nullptr instead.
Similarly, fix __asan_handle_no_return so that it gives up rather than
try something that may crash.
Differential Revision: https://reviews.llvm.org/D46459
llvm-svn: 332888
Summary:
The static TLS vector for the main thread on NetBSD/i386 can be
unaligned in terms of the shadow granularity. Align the start of it with
Round Down and end of it with Round Up operations for the shadow
granularity shift.
Example static TLS vector ranges on NetBSD/i386:
tls_begin_=0xfbee7244 tls_end_=0xfbee726c.
ClearShadowForThreadStackAndTLS() is called from the Main Thread
bootstrap functions.
This change restores the NetBSD x86 32-bit (i386) support.
Sponsored by <The NetBSD Foundation>
Reviewers: vitalybuka, joerg
Reviewed By: vitalybuka
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D46585
llvm-svn: 332792
This is not needed after we've forked the Myriad version. Not to
mention it produces a compiler warning.
Differential Revision: https://reviews.llvm.org/D47054
llvm-svn: 332744
The Myriad RTEMS memory system has a few unique aspects that
require support in the ASan run-time.
- A limited amount of memory (currently 512M).
- No virtual memory, no memory protection.
- DRAM starts at address 0x80000000. Other parts of memory may be
used for MMIO, etc.
- The second highest address bit is the "cache" bit, and 0x80000000
and 0x84000000 alias to the same memory.
To support the above, we make the following changes:
- Use a ShadowScale of 5, to reduce shadow memory overhead.
- Adjust some existing macros to remove assumption that the lowest
memory address is 0.
- add a RawAddr macro that on Myriad strips the cache bit from the
input address, before using the address for shadow memory (for other
archs this does nothing).
- We must check that an address is in DRAM range before using it to
index into shadow memory.
Differential Revision: https://reviews.llvm.org/D46456
llvm-svn: 332690
This commit contains the trivial portion of the port of ASan to
Myriad RTEMS.
- Whitelist platform in sanitizer_platform.h, ubsan_platform.h
- Turn off general interception
- Use memset for FastPoisonShadow
- Define interception wrappers
- Set errno symbol correctly
- Enable ASAN_LOW_MEMORY
- Enable preinit array
- Disable slow unwinding
- Use fuchsia offline symbolizer
- Disable common code for: InitializeShadowMemory, CreateMainThread,
AsanThread::ThreadStart, StartReportDeadlySignal,
MaybeReportNonExecRegion.
Differential Revision: https://reviews.llvm.org/D46454
llvm-svn: 332681
This gives us something to insert into the shadow gap for systems that
don't have memory protection turned on there (i.e. on Myriad).
Differential Revision: https://reviews.llvm.org/D46457
llvm-svn: 332557
This appears to be a copy/paste artifact from `AddrIsInHighMem`. It was caught by Firefox's jit-tests on Win64.
Differential Revision: https://reviews.llvm.org/D46291
llvm-svn: 332092
Replace decltype(memcpy) with decltype(__asan_memcpy) because memcpy
has not been defined in any headers on RTEMS. Similarly for memmove
and memset.
Differential Revision: https://reviews.llvm.org/D46625
llvm-svn: 332047
If detect-stack-use-after-return is on, initialize fake stack during
AsanThread::Init(), rather than lazily. This is required on Myriad.
From kcc: "There used to be a reason why this was done lazily, but I
don't remember if we still have that reason." Tested on x86.
Differential Revision: https://reviews.llvm.org/D46626
llvm-svn: 332033
Summary:
Leak checker needs to suspend all process threads. If we have some running
thread in registry but not suspended we can have false leak report. So we will
report this case here for future debugging.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D46663
llvm-svn: 331936
Fuchsia is no longer treated as UNIX which means we need to explicitly
enable building of shared versions of runtimes.
Differential Revision: https://reviews.llvm.org/D46609
llvm-svn: 331922
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
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
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
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
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
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
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:
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:
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:
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
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:
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:
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
Evgeniy Stepanov