Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every `unreachable` instruction. However,
the optimizer will remove code after calls to functions marked with
`noreturn`. To avoid this UBSan removes `noreturn` from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
`_asan_handle_no_return` before `noreturn` functions. This is important
for functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* `longjmp` (`longjmp` itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the `noreturn` attributes are missing and ASan
cannot unpoison the stack, so it has false positives when stack
unwinding is used.
Changes:
# UBSan now adds the `expect_noreturn` attribute whenever it removes
the `noreturn` attribute from a function
# ASan additionally checks for the presence of this attribute
Generated code:
```
call void @__asan_handle_no_return // Additionally inserted to avoid false positives
call void @longjmp
call void @__asan_handle_no_return
call void @__ubsan_handle_builtin_unreachable
unreachable
```
The second call to `__asan_handle_no_return` is redundant. This will be
cleaned up in a follow-up patch.
rdar://problem/40723397
Reviewers: delcypher, eugenis
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D56624
llvm-svn: 352003
This saves a cbz+cold call in the interceptor ABI, as well as a realign
in both ABIs, trading off a dcache entry against some branch predictor
entries and some code size.
Unfortunately the functionality is hidden behind a flag because ifunc is
known to be broken on static binaries on Android.
Differential Revision: https://reviews.llvm.org/D57084
llvm-svn: 351989
Reports correct size and tags when either size is not power of two
or offset to bad granule is not zero.
Differential revision: https://reviews.llvm.org/D56603
llvm-svn: 351730
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
Whenever a large shadow region is tagged to zero, madvise(DONT_NEED)
as much of it as possible.
This reduces shadow RSS on Android by 45% or so, and total memory use
by 2-4%, probably even more on long running multithreaded programs.
CPU time seems to be in the noise.
Reviewers: kcc, pcc
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D56757
llvm-svn: 351620
Summary:
This replaces the sanitizer tool list (used for generating
sanitizer_common configurations) with a tool list derived from
existing build system information.
Previously sanitizer_common had its own list of supported sanitizer
tools. This was bad because it was out of sync with the rest of the
build system. Notably it meant that the sanitizer_common runtime was
only being tested on Darwin the ASan dylib and not the other sanitizer
dylibs that are built for Darwin (LSan, TSan, and UBSan).
Unfortunately enabling the tests against other sanitizer dylibs has lead
to some test failures on Darwin. For now they've been marked as
XFAIL until the failures can investigated properly.
For Windows and Android we use the old sanitizer tool list to try avoid
bot breakages.
rdar://problem/47143078
Reviewers: kubamracek, george.karpenkov, yln, samsonov, vitalybuka, krytarowski
Subscribers: srhines, mgorny, fedor.sergeev, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D55740
llvm-svn: 351398
Looks like the sanitizer-x86_64-linux-android bot started failing
because -pie is still needed when targeting API levels < 16 (which
is the case by default for arm and i686).
llvm-svn: 351270
Summary:
Remove code for handling unstable edges from libFuzzer since
it has not been found useful.
Differential Revision: https://reviews.llvm.org/D56730
llvm-svn: 351262
Add a ANDROID_SERIAL_FOR_TESTING CMake variable. This lets you
run the tests with multiple devices attached without having to set
ANDROID_SERIAL.
Add a mechanism for pushing files to the device. Currently most
sanitizers require llvm-symbolizer and the sanitizer runtime to
be pushed to the device. This lets the sanitizer make this happen
automatically before running the tests by specifying the paths in
the lit.site.cfg file.
Differential Revision: https://reviews.llvm.org/D56712
llvm-svn: 351260
-pie -Wl,--enable-new-dtags are no longer needed because
the driver passes them by default as of r316606.
Prepend -fuse-ld=gold instead of appending it so that the linker can
be overridden using COMPILER_RT_TEST_COMPILER_CFLAGS.
Differential Revision: https://reviews.llvm.org/D56697
llvm-svn: 351252
Summary:
This is the compiler-rt part.
The clang part is D54589.
This is a second commit, the original one was r351106,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.
Now, i have fundamentally changed the testing approach:
i malloc a few bytes, intentionally mis-align the pointer
(increment it by one), and check that. Also, i have decreased
the expected alignment. This hopefully should be enough to pacify
all the bots. If not, i guess i might just drop the two 'bad' tests.
Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse
Reviewed By: morehouse
Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D54590
llvm-svn: 351178
Summary:
The test uses `nullptr` which can break running the test if the
compiler happens to be using something older than C++11 as the default
language standard. Avoid this by explicitly setting the standard.
rdar://problem/47253542
Reviewers: eugenis, yln, vitalybuka
Subscribers: kubamracek, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D56667
llvm-svn: 351169
r351134 tried to disable these tests by using 'UNSUPPORTED: *' but '*'
is not supported for UNSUPPORTED like it is for XFAIL. Update these
tests to use XFAIL for now in order to silence x86_64-linux and
x86_64-linux-android.
llvm-svn: 351153
And they are faling on clang-cmake-armv7-full too.
*ONLY* these two.
I'm not sure what to make of it.
Perhaps doing a malloc and checking that pointer will
make them fail as expected?
llvm-svn: 351134
Once again, just like with r338296, these tests seem to only have
failed sanitizer-x86_64-linux-android, so let's just disable them,
since that seems like the pre-established practice here..
To be noted, they failed on some configs there, but not all,
so it is not XFAIL.
llvm-svn: 351119
Disable tests requiring sunrpc when the relevant headers are missing.
In order to accommodate that, move the header check
from sanitizer_common to base-config-ix, and define the check result
as a global variable there. Use it afterwards both for definition
needed by sanitizer_common, and to control 'sunrpc' test feature.
While at it, remove the append_have_file_definition macro that was used
only once, and no longer fits the split check-definition.
Bug report: https://github.com/google/sanitizers/issues/974
Differential Revision: https://reviews.llvm.org/D47819
llvm-svn: 351109
This reverts r350806 which marked some tests as UNSUPPORTED on ARM and
instead reintroduces the old code path only for Thumb, since that seems
to be the only target that broke.
It would still be nice to find the root cause of the breakage, but with
the branch point for LLVM 8.0 scheduled for next week it's better to put
things in a stable state while we investigate.
Differential Revision: https://reviews.llvm.org/D56594
llvm-svn: 351040
LLVM started exporting targets for utilites with https://reviews.llvm.org/rL350959, which broke compiler-rt standalone builds because it was used to define FileCheck manually.
Changed this, so FileCheck gets imported now.
llvm-svn: 350973
- If entries are properly copied (there were a bug in FreeBSD implementation in earlier version), or list properly reset.
Reviewers: vitalybuka, krytarowski
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D56562
llvm-svn: 350919
Summary:
It has been superseded by the `ignore_noninstrumented_modules` flag and is no longer needed.
Also simplify a test that checks that `mmap_interceptor` respects ignore annotations (`thr->ignore_reads_and_writes `).
Relevant: https://reviews.llvm.org/rL269855
<rdar://problem/46263073> Remove obsolete Apple-specific suppression option
Reviewers: dcoughlin, kubamracek, dvyukov, delcypher
Reviewed By: dvyukov
Subscribers: jfb, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D55075
llvm-svn: 350883
This patch implements the long double __floattitf (int128_t) method for
PowerPC -- specifically to convert a 128 bit integer into a long double
(IBM double-double).
To invoke this method, one can do so by linking against compiler-rt, via the
--rtlib=compiler-rt command line option supplied to clang.
Differential Revision: https://reviews.llvm.org/D54313/
llvm-svn: 350818
This patch implements the __uint128_t __fixunstfti (long double) method for
PowerPC -- specifically to convert a long double (IBM double-double) to an
unsigned 128 bit integer.
The general approach of this algorithm is to convert the high and low doubles
of the long double and add them together if the doubles fit within 64 bits.
However, additional adjustments and scaling is performed when the high or low
double does not fit within a 64 bit integer.
To invoke this method, one can do so by linking against compiler-rt, via the
--rtlib=compiler-rt command line option supplied to clang.
Differential Revision: https://reviews.llvm.org/D54911
llvm-svn: 350815
Temporarily mark a couple of tests as UNSUPPORTED until we figure out
why they fail on the thumb bots.
The failure was introduced in
r350139 - Add support for background thread on NetBSD in ASan.
llvm-svn: 350806
XFAIL the tests known to fail with glibc-2.27+. This takes away
the burden of handling known failures from users, and ensures that
we will be verbosely informed when they actually start working again.
Bug report: https://bugs.llvm.org/show_bug.cgi?id=37804
Differential Revision: https://reviews.llvm.org/D56062
llvm-svn: 350717
Now that memory intrinsics are instrumented, it's more likely that
CheckAddressSized will be called with size 0. (It was possible before
with IR like:
%val = load [0 x i8], [0 x i8]* %ptr
but I don't think clang will generate IR like that and the optimizer
would normally remove it by the time it got anywhere near our pass
anyway). The right thing to do in both cases is to disable the
addressing checks (since the underlying memory intrinsic is a no-op),
so that's what we do.
Differential Revision: https://reviews.llvm.org/D56465
llvm-svn: 350683
Summary:
This patch lets ASan run when /proc is not accessible (ex. not mounted
yet). It includes a special test-only flag that emulates this condition
in an unpriviledged process.
This only matters on Linux, where /proc is necessary to enumerate
virtual memory mappings.
Reviewers: vitalybuka, pcc, krytarowski
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D56141
llvm-svn: 350590
Summary:
Objective-C employs tagged pointers, that is, small objects/values may be encoded directly in the pointer bits. The resulting pointer is not backed by an allocation/does not point to a valid memory. TSan infrastructure requires a valid address for `Acquire/Release` and `Mutex{Lock/Unlock}`.
This patch establishes such a mapping via a "dummy allocation" for each encountered tagged pointer value.
Reviewers: dcoughlin, kubamracek, dvyukov, delcypher
Reviewed By: dvyukov
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D56238
llvm-svn: 350556
The Android dynamic loader has a non-standard feature that allows
libraries such as the hwasan runtime to interpose symbols even after
the symbol already has a value. The new value of the symbol is used to
relocate libraries loaded after the interposing library, but existing
libraries keep the old value. This behaviour is activated by the
DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to
the linker, which is what we already do to link the hwasan runtime.
What this means in practice is that if we have .so files that depend
on interceptor-mode hwasan without the main executable depending on
it, some of the libraries in the process will be using the hwasan
allocator and some will be using the system allocator, and these
allocators need to interact somehow. For example, if an instrumented
library calls a function such as strdup that allocates memory on
behalf of the caller, the instrumented library can reasonably expect
to be able to call free to deallocate the memory.
We can handle that relatively easily with hwasan by using tag 0 to
represent allocations from the system allocator. If hwasan's realloc
or free functions are passed a pointer with tag 0, the system allocator
is called.
One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.
Differential Revision: https://reviews.llvm.org/D55986
llvm-svn: 350427
Summary:
Replace the 32-bit allocator with a 64-bit one with a non-constant
base address, and reduce both the number of size classes and the maximum
size of per-thread caches.
As measured on [1], this reduces average weighted memory overhead
(MaxRSS) from 26% to 12% over stock android allocator. These numbers
include overhead from code instrumentation and hwasan shadow (i.e. not a
pure allocator benchmark).
This switch also enables release-to-OS functionality, which is not
implemented in the 32-bit allocator. I have not seen any effect from
that on the benchmark.
[1] https://android.googlesource.com/platform/system/extras/+/master/memory_replay/
Reviewers: vitalybuka, kcc
Subscribers: kubamracek, cryptoad, llvm-commits
Differential Revision: https://reviews.llvm.org/D56239
llvm-svn: 350370
Add tests for the more character-oriented functions, that is:
- fputc(), putc() and putchar()
- getc_unlocked()
- putc_unlocked() and putchar_unlocked()
Differential Revision: https://reviews.llvm.org/D56152
llvm-svn: 350229
Rewrite the tests for Posix functions that silently 'return 1'
or 'exit(1)' on error, to instead verbosely report the error using
assert. This is based on requests made in review of D56136.
Differential Revision: https://reviews.llvm.org/D56149
llvm-svn: 350227
Add two new test cases that test the following stdio.h functions:
- clearerr()
- feof()
- ferror()
- fileno()
- fgetc()
- getc()
- ungetc()
Differential Revision: https://reviews.llvm.org/D56136
llvm-svn: 350225
Summary:
Change the point of calling MaybeStartBackgroudThread() from AsanInitInternal()
that is too early on NetBSD to a constructor (with aid of C++11 lambda construct).
Enable the code for background thread as is for NetBSD.
Rename test/sanitizer_common/TestCases/Linux/hard_rss_limit_mb_test.cc
to test/sanitizer_common/TestCases/hard_rss_limit_mb_test.cc and allow runs
on NetBSD. This tests passes correctly.
Reviewers: vitalybuka, joerg, eugenis
Reviewed By: eugenis
Subscribers: eugenis, kubamracek, fedor.sergeev, llvm-commits, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D55887
llvm-svn: 350139
- Disabled on purpose on Android and Darwin platform (for now).
- Darwin supports it, would need interception in its specific code before enabling it.
- Linux does not support it but only via third party library.
- Android supports it via bionic however it is known to have issue with older versions of the implementations. Can be enabled by an Android committer later on if necessary once there is more 'certainity'/been more tested.
Reviewers: krytarowski, vitalybuka
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D56125
llvm-svn: 350123
Revert r350104 "[asan] Fix build on windows."
Revert r350101 "[asan] Support running without /proc."
These changes break Mac build, too.
llvm-svn: 350112
Summary: They happen to work out of the box.
Reviewers: rtrieu, vitalybuka
Subscribers: kubamracek, fedor.sergeev, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D56088
llvm-svn: 350103
Summary:
This patch lets ASan run when /proc is not accessible (ex. not mounted
yet). It includes a special test-only flag that emulates this condition
in an unpriviledged process.
This only matters on Linux, where /proc is necessary to enumerate
virtual memory mappings.
Reviewers: pcc, vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D55874
llvm-svn: 350101
Summary:
By an accident part of the tests contained hardcoded checksums
for external files that will differ between setups.
Reviewers: mgorny
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D56104
llvm-svn: 350097
Summary:
By an accident part of the tests contained hardcoded checksums
for external files that will differ between setups.
Reviewers: mgorny
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D56105
llvm-svn: 350096
Summary:
By an accident part of the tests contained hardcoded checksums
for external files that will differ between setups.
Reviewers: mgorny
Subscribers: kubamracek, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D56106
llvm-svn: 350095
Reviewers: krytarowski
Reviewed By: krytarowski
Differential Revision: https://reviews.llvm.org/D56009
M lib/sanitizer_common/sanitizer_common_interceptors.inc
M lib/sanitizer_common/sanitizer_platform_interceptors.h
M lib/sanitizer_common/sanitizer_platform_limits_freebsd.cc
M lib/sanitizer_common/sanitizer_platform_limits_freebsd.h
D test/sanitizer_common/TestCases/NetBSD/regex.cc
A + test/sanitizer_common/TestCases/Posix/regex.cc
llvm-svn: 350002
Summary:
NetBSD uses typical UNIX interfaces.
All tests pass except instrprof-dlopen-dlclose-gcov.test, as there
is not supported semantics of atexit(3) in dlopen(3)ed+dlclose(3)d
DSO.
NetBSD also ships an older version of LLVM profile (ABI v.2 predating
ABI v.4 in upstream version) inside libc. That copy has been manually
removed during the porting and testing process of the upstream version
to NetBSD. Otherwise there were conflicts between them two.
Reviewers: joerg, vitalybuka, vsk
Subscribers: srhines, fedor.sergeev, llvm-commits, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D55997
llvm-svn: 349994
Summary:
This is a change requested by Vitaly Buka as prerequisite to landing
https://reviews.llvm.org/D55740.
Reviewers: vitalybuka, kubamracek
Subscribers: mgorny, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D55939
llvm-svn: 349897
Summary:
Support running with no open file descriptors (as may happen to
"init" process on linux).
* Remove a check that writing to stderr succeeds.
* When opening a file (ex. for log_path option), dup the new fd out of
[0, 2] range to avoid confusing the program.
(2nd attempt, this time without the sanitizer_rtems change)
Reviewers: pcc, vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D55801
llvm-svn: 349817
This is patch complements D55117 implementing __hwasan_mem*
functions in runtime
Differential revision: https://reviews.llvm.org/D55554
llvm-svn: 349730
Summary:
Support running with no open file descriptors (as may happen to
"init" process on linux).
* Remove a check that writing to stderr succeeds.
* When opening a file (ex. for log_path option), dup the new fd out of
[0, 2] range to avoid confusing the program.
Reviewers: pcc, vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D55801
llvm-svn: 349699
This patch aims to enable the tests for the compiler-rt builtin functions (that
currently already exist within compiler-rt) for PowerPC 64bit LE (ppc64le).
Previously when unit tests are run, these tests would be reported as
UNSUPPORTED. This patch updates the REQUIRES line for each test (to enable for
ppc64le), and each test is linked against compiler-rt when running.
Differential Revision: https://reviews.llvm.org/D54449
llvm-svn: 349634
I tricked myself into thinking that deadlock detection is off by default in TSan by looking at the default value of the detect_deadlocks flag and outdated docs. (Created a pull request to update docs.)
I even managed to confuse others: https://groups.google.com/forum/#!topic/thread-sanitizer/xYvnAYwtoDk
However, the default value is overwritten in code (TSan_flags.cc:InitializeFlags). The TSan/deadlock tests also rely on this
This changes aligns the default value of the flag with the actual default behavior.
Author: yln (Julian Lettner)
Reviewed in: https://reviews.llvm.org/D55846
llvm-svn: 349609
Summary:
unnamed_addr is still useful for detecting of ODR violations on vtables
Still unnamed_addr with lld and --icf=safe or --icf=all can trigger false
reports which can be avoided with --icf=none or by using private aliases
with -fsanitize-address-use-odr-indicator
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: kubamracek, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D55799
llvm-svn: 349555
Summary:
private and internal: should not trigger ODR at all.
unnamed_addr: current ODR checking approach fail and rereport false violation if
a linker merges such globals
linkonce_odr, weak_odr: could cause similar problems and they are already not
instrumented for ELF.
Reviewers: eugenis, kcc
Subscribers: kubamracek, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D55621
llvm-svn: 349015
Julian Lettner