Do not add an lld dependency when this target does not exist. In this
case the system installation of lld is used (or whatever is detected
with -fuse-ld=lld by default).
Summary:
This is a clean patch using the last diff of D69265, but using git
instead of svn, since svn went ro and arc was making my life harded
than it needed to be.
I was going to introduce a couple more lists and realized that our
lists are currently a bit all over the place. While we have a singly
linked list type relatively well defined, we are using doubly linked
lists defined on the fly for the stats and for the secondary blocks.
This CL adds a doubly linked list object, reorganizing the singly list
one to extract as much of the common code as possible. We use this
new type in the stats and the secondary. We also reorganize the list
tests to benefit from this consolidation.
There are a few side effect changes such as using for iterator loops
that are, in my opinion, cleaner in a couple of places.
Reviewers: hctim, morehouse, pcc, cferris
Reviewed By: hctim
Subscribers: jfb, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69516
Use new control bits CTR_EL0.DIC and CTR_EL0.IDC to discover the d-cache
cleaning and i-cache invalidation requirements for instruction-to-data
coherence. This matches the behavior in the latest libgcc.
Author: Shaokun Zhang <zhangshaokun@hisilicon.com>
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D69247
In cmake, if TEST_COMPILE_ONLY is set
compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake invokes try_compile_only()
but try_compile_only() is defined in BuiltinTests.cmake and is not included in
CompilerRTDarwinUtils.cmake. This patch simply includes it BuiltinTests.
Differential Revision: https://reviews.llvm.org/D69410
Summary:
Right now all hwasan tests on Android are silently disabled because they
require "has_lld" and standalone compiler-rt can not (and AFAIK was
never able to) set it.
Reviewers: pcc
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69405
Summary:
GCC would like to emit a function call to report a tag mismatch
rather than hard-code the `brk` instruction directly.
__hwasan_tag_mismatch_stub contains most of the functionality to do
this already, but requires exposure in the dynamic library.
This patch moves __hwasan_tag_mismatch_stub outside of the anonymous
namespace that it was defined in and declares it in
hwasan_interface_internal.h.
We also add the ability to pass sizes larger than 16 bytes to this
reporting function by providing a fourth parameter that is only looked
at when the size provided is not in the original accepted range.
This does not change the behaviour where it is already being called,
since the previous definition only accepted sizes up to 16 bytes and
hence the change in behaviour is not seen by existing users.
The change in declaration does not matter, since the only existing use
is in the __hwasan_tag_mismatch function written in assembly.
Reviewers: eugenis, kcc, pcc, #sanitizers
Reviewed By: eugenis, #sanitizers
Subscribers: kristof.beyls, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69113
Patch by Matthew Malcomson <matthew.malcomson@arm.com>
Summary:
GCC would like to emit a function call to report a tag mismatch
rather than hard-code the `brk` instruction directly.
__hwasan_tag_mismatch_stub contains most of the functionality to do
this already, but requires exposure in the dynamic library.
This patch moves __hwasan_tag_mismatch_stub outside of the anonymous
namespace that it was defined in and declares it in
hwasan_interface_internal.h.
We also add the ability to pass sizes larger than 16 bytes to this
reporting function by providing a fourth parameter that is only looked
at when the size provided is not in the original accepted range.
This does not change the behaviour where it is already being called,
since the previous definition only accepted sizes up to 16 bytes and
hence the change in behaviour is not seen by existing users.
The change in declaration does not matter, since the only existing use
is in the __hwasan_tag_mismatch function written in assembly.
Tested with gcc and clang on an AArch64 vm.
Reviewers: eugenis, kcc, pcc, #sanitizers
Reviewed By: eugenis, #sanitizers
Subscribers: kristof.beyls, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69113
Within the last two weeks, the Builtins-*-sunos :: clear_cache_test.c started to FAIL
on Solaris. Running it under truss shows
mmap(0x00000000, 128, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 0, 0) Err#22 EINVAL
_exit(1)
While there are several possible reasons mmap can return EINVAL on Solaris, it turns
out it's this one (from mmap(2)):
MAP_ANON was specified, but the file descriptor was not
-1.
And indeed even the Linux mmap(2) documents this as unportable:
MAP_ANONYMOUS
The mapping is not backed by any file; its contents are initial‐
ized to zero. The fd argument is ignored; however, some imple‐
mentations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is
specified, and portable applications should ensure this. The
This patch follows this advise. Tested on x86_64-pc-linux-gnu, amd64-pc-solaris2.11
and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D68455
llvm-svn: 375490
Summary:
Right now all hwasan tests on Android are silently disabled because they
require "has_lld" and standalone compiler-rt can not (and AFAIK was
never able to) set it.
Reviewers: pcc, dyung
Subscribers: dberris, mgorny, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69196
llvm-svn: 375472
Android links the unwinder library to every DSO. The problem is,
unwinder has global state, and hwasan implementation of personality
function wrapper happens to rub it the wrong way.
Switch the test to static libc++ as a temporary workaround.
llvm-svn: 375471
When the %m filename pattern is used, the filename is unique to each
image, so the cached value is wrong.
It struck me that the full filename isn't something that's recomputed
often, so perhaps it doesn't need to be cached at all. David Li pointed
out we can go further and just hide lprofCurFilename. This may regress
workflows that depend on using the set-filename API to change filenames
across all loaded DSOs, but this is expected to be very rare.
rdar://55137071
Differential Revision: https://reviews.llvm.org/D69137
llvm-svn: 375301
Summary:
This has been an experiment with late malloc interposition, made
possible by a non-standard feature of the Android dynamic loader.
Reviewers: pcc, mmalcomson
Subscribers: srhines, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69199
llvm-svn: 375296
Android now allocates only 8 fixed TLS slots. Somehow we were getting away
with using a non-existent slot until now, but in some cases the TLS slots
were being placed at the end of a page, which led to a segfault at startup.
Differential Revision: https://reviews.llvm.org/D69191
llvm-svn: 375276
Glibc has recently introduced changed to the mode field in ipc_perm in commit
2f959dfe849e0646e27403f2e4091536496ac0f0. For Arm this means that the mode
field no longer has the same size.
This causes an assert failure against libsanitizer's internal copy of ipc_perm.
Since this change can't be easily detected I am adding arm to the list of
targets that are excluded from this check.
Patch by: Tamar Christina
Differential Revision: https://reviews.llvm.org/D69104
llvm-svn: 375220
Summary:
Until now AArch64 development has been on patched kernels that have an always
on relaxed syscall ABI where tagged pointers are accepted.
The patches that have gone into the mainline kernel rely on each process opting
in to this relaxed ABI.
This commit adds code to choose that ABI into __hwasan_init.
The idea has already been agreed with one of the hwasan developers
(http://lists.llvm.org/pipermail/llvm-dev/2019-September/135328.html).
The patch ignores failures of `EINVAL` for Android, since there are older versions of the Android kernel that don't require this `prctl` or even have the relevant values. Avoiding EINVAL will let the library run on them.
I've tested this on an AArch64 VM running a kernel that requires this
prctl, having compiled both with clang and gcc.
Patch by Matthew Malcomson.
Reviewers: eugenis, kcc, pcc
Reviewed By: eugenis
Subscribers: srhines, kristof.beyls, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68794
llvm-svn: 375166
This is a follow up to r375150 to unbreak the `clang-ppc64be-linux` bot.
The commit caused running the tests to fail due to
```
llvm-lit:
/home/buildbots/ppc64be-clang-multistage-test/clang-ppc64be-multistage/llvm/projects/compiler-rt/test/builtins/Unit/lit.cfg.py:116:
fatal: builtins_source_features contains duplicates:
['librt_has_divtc3']
```
This commit should be reverted once the build system bug for powerpc is
fixed.
llvm-svn: 375162
Summary:
If a platform removes some builtin implementations (e.g. via the
Darwin-excludes mechanism) then this can lead to test failures because
the test expects an implementation to be available.
To solve this lit features are added for each configuration based
on which sources are included in the builtin library. The features
are of the form `librt_has_<name>` where `<name>` is the name of the
source file with the file extension removed. This handles C and
assembly sources.
With the lit features in place it is possible to make certain tests
require them.
Example:
```
REQUIRES: librt_has_comparedf2
```
All top-level tests in `test/builtins/Unit` (i.e. not under
`arm`, `ppc`, and `riscv`) have been annotated with the appropriate
`REQUIRES: librt_has_*` statement.
rdar://problem/55520987
Reviewers: beanz, steven_wu, arphaman, dexonsmith, phosek, thakis
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D68064
llvm-svn: 375150
After r375041 llvm-symbolizer uses it for demangling instead of
UnDecorateSymbolName. LLVM puts spaces after commas while Microsoft does
not.
llvm-svn: 375147
Summary:
In the macOS 10.15 SDK the ability to link i386 binaries was removed and
in the corresponding OS it is not possible to run macOS i386 binaries.
The consequence of these changes meant that targets like `check-asan`
would fail because:
* Unit tests could not be linked for i386
* Lit tests for i386 would fail due to not being able to execute
compiled binaries.
The simplest fix to this is to simply disable building for i386 for
macOS when using the 10.15 SDK (or newer). This disables building the
i386 slice for most compiler-rt libraries and consequently disables the
unit and lit tests for macOS i386.
Note that because the `DARWIN_osx_ARCHS` CMake variable is a cache
variable this patch will have no affect on existing builds unless
the existing cache variable is deleted. The simplest way to deal with
this is delete existing builds and just do a fresh configure.
Note this should not affect the builtins which are managed with
the `DARWIN_osx_BUILTIN_ARCHS` CMake cache variable.
For those who wish to force using a particular set of architectures when
using newer SDKs passing `-DDARWIN_osx_ARCHS=i386;x86_64;x86_64h` to
CMake should provide a usable (but completely unsupported) workaround.
rdar://problem/55668535
rdar://problem/47939978
Reviewers: kubamracek, yln, azhar, kcc, dvyukov, vitalybuka, cryptoad, eugenis, thakis, phosek
Subscribers: mgorny, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D68292
llvm-svn: 374977
This #define is in the non-Go ppc64le build but not in the Go build.
Reviewed-in: https://reviews.llvm.org/D68046
Author: randall77 (Keith Randall)
llvm-svn: 374868
The ExecuteCommand function in fuchsia used to prefix the
getOutputFile for each command run with the artifact_prefix flag if
it was available, because fuchsia components don't have a writable working
directory. However, if a file with a global path is provided, fuchsia
should honor that.
An example of this is using the global /tmp directory to store stuff.
In fuchsia it ended up being translated to data///tmp, whereas we want
to make sure it is using /tmp (which is available to components using the
isolated-temp feature).
To test this I made the change, compiled fuchsia with this toolchain and
ran a fuzzer with the -fork=1 flag (that mode makes use of the /tmp
directory). I also tested that normal fuzzing workflow was not affected
by this.
Author: charco (Marco Vanotti)
Differential Revision: https://reviews.llvm.org/D68774
llvm-svn: 374612
Updated: Removed offending TODO comment.
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
> llvm-svn: 374265
llvm-svn: 374384
- Available from 12.x branch, by the time it lands next year in FreeBSD tree, the 11.x's might be EOL.
- Intentionally changed the getrandom test to C code as with 12.0 (might be fixed in CURRENT since), there is a linkage issue in C++ context.
Reviewers: emaste, dim, vitalybuka
Reviewed-By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68451
llvm-svn: 374315
Summary:
Quote from http://eel.is/c++draft/expr.add#4:
```
4 When an expression J that has integral type is added to or subtracted
from an expression P of pointer type, the result has the type of P.
(4.1) If P evaluates to a null pointer value and J evaluates to 0,
the result is a null pointer value.
(4.2) Otherwise, if P points to an array element i of an array object x with n
elements ([dcl.array]), the expressions P + J and J + P
(where J has the value j) point to the (possibly-hypothetical) array
element i+j of x if 0≤i+j≤n and the expression P - J points to the
(possibly-hypothetical) array element i−j of x if 0≤i−j≤n.
(4.3) Otherwise, the behavior is undefined.
```
Therefore, as per the standard, applying non-zero offset to `nullptr`
(or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value
from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined,
i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.)
To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer
is undefined, although Clang front-end pessimizes the code by not lowering
that info, so this UB is "harmless".
Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`)
LLVM middle-end uses those guarantees for transformations.
If the source contains such UB's, said code may now be miscompiled.
Such miscompilations were already observed:
* https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html
* https://github.com/google/filament/pull/1566
Surprisingly, UBSan does not catch those issues
... until now. This diff teaches UBSan about these UB's.
`getelementpointer inbounds` is a pretty frequent instruction,
so this does have a measurable impact on performance;
I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%),
and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark:
(all measurements done with LLVM ToT, the sanitizer never fired.)
* no sanitization vs. existing check: average `+21.62%` slowdown
* existing check vs. check after this patch: average `22.04%` slowdown
* no sanitization vs. this patch: average `48.42%` slowdown
Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers
Reviewed By: rsmith
Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67122
llvm-svn: 374293
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
llvm-svn: 374265
Evgenii Stepanov