Based on comments in D91466, we can make the current implementation
linux-speciic. The fuchsia implementation will just be a call to
`__sanitizer_fill_shadow`.
Differential Revision: https://reviews.llvm.org/D105663
The new name is something less linux-y and more platform generic. Once we
finalize the tagged pointer ABI in zircon, we will do the appropriate check
for fuchsia to see that TBI is enabled.
Differential Revision: https://reviews.llvm.org/D105667
This reverts commit 52aeacfbf5.
There isn't full agreement on a path forward yet, but there is agreement that
this shouldn't land as-is. See discussion on https://reviews.llvm.org/D105338
Also reverts unreviewed "[clang] Improve `-Wnull-dereference` diag to be more in-line with reality"
This reverts commit f4877c78c0.
And all the related changes to tests:
This reverts commit 9a0152799f.
This reverts commit 3f7c9cc274.
This reverts commit 329f8197ef.
This reverts commit aa9f58cc2c.
This reverts commit 2df37d5ddd.
This reverts commit a72a441812.
Store to null is deleted, so the test no longer did what it was expecting to do.
Conceal that by creating null pointer in a more elaborate way,
thus retaining original test coverage.
trapOnAddress is designed to SEGV on a specific address. Unfortunately,
with an IR change, __builtin_unreachable() ends up doing DCE on things
that have side effects, like the load that causes the trap.
Change to __builtin_trap() to avoid the optimisation.
Root cause is still an LLVM bug, and tracked in
https://bugs.llvm.org/show_bug.cgi?id=47480.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D105654
This contains all the definitions required by hwasan for the fuchsia
implementation and can be landed independently from the remaining parts of D91466.
Differential Revision: https://reviews.llvm.org/D103936
This disables use of hwasan interceptors which we do not use on Fuchsia. This
explicitly sets the macro for defining the hwasan versions of new/delete.
Differential Revision: https://reviews.llvm.org/D103544
This patch splits up hwasan thread creation between `__sanitizer_before_thread_create_hook`,
`__sanitizer_thread_create_hook`, and `__sanitizer_thread_start_hook`.
The linux implementation creates the hwasan thread object inside the
new thread. On Fuchsia, we know the stack bounds before thread creation,
so we can initialize part of the thread object in `__sanitizer_before_thread_create_hook`,
then initialize the stack ring buffer in `__sanitizer_thread_start_hook`
once we enter the thread.
Differential Revision: https://reviews.llvm.org/D104085
Update the asan_symbolize_script for changes in argparse output
in Python 3.10. The parser output 'options' instead of 'optional
arguments'.
Differential Revision: https://reviews.llvm.org/D105489
The __llvm_prf_names section uses SHF_GNU_RETAIN. However, GNU ld before 2015-10
(https://sourceware.org/bugzilla/show_bug.cgi?id=19161) neither supports it nor
retains __llvm_prf_names according to __start___llvm_prf_names. So --gc-sections
does not work on such old GNU ld.
This is not a problem for gold and sufficiently new lld.
We would find an address with matching tag, only to discover in
ShowCandidate that it's very far away from [stack].
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D105197
If the fault address is at the boundary of memory regions, this could
cause us to segfault otherwise.
Ran test with old compiler_rt to make sure it fails.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D105032
Compiling compiler-rt with Clang modules and libc++ revealed that the
global `operator new` is being called without including `<new>`.
Differential Revision: https://reviews.llvm.org/D105401
This change introduces libMutagen/libclang_rt.mutagen.a as a subset of libFuzzer/libclang_rt.fuzzer.a. This library contains only the fuzzing strategies used by libFuzzer to produce new test inputs from provided inputs, dictionaries, and SanitizerCoverage feedback.
Most of this change is simply moving sections of code to one side or the other of the library boundary. The only meaningful new code is:
* The Mutagen.h interface and its implementation in Mutagen.cpp.
* The following methods in MutagenDispatcher.cpp:
* UseCmp
* UseMemmem
* SetCustomMutator
* SetCustomCrossOver
* LateInitialize (similar to the MutationDispatcher's original constructor)
* Mutate_AddWordFromTORC (uses callbacks instead of accessing TPC directly)
* StartMutationSequence
* MutationSequence
* DictionaryEntrySequence
* RecommendDictionary
* RecommendDictionaryEntry
* FuzzerMutate.cpp (which now justs sets callbacks and handles printing)
* MutagenUnittest.cpp (which adds tests of Mutagen.h)
A note on performance: This change was tested with a 100 passes of test/fuzzer/LargeTest.cpp with 1000 runs per pass, both with and without the change. The running time distribution was qualitatively similar both with and without the change, and the average difference was within 30 microseconds (2.240 ms/run vs 2.212 ms/run, respectively). Both times were much higher than observed with the fully optimized system clang (~0.38 ms/run), most likely due to the combination of CMake "dev mode" settings (e.g. CMAKE_BUILD_TYPE="Debug", LLVM_ENABLE_LTO=OFF, etc.). The difference between the two versions built similarly seems to be "in the noise" and suggests no meaningful performance degradation.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D102447
We need the compiler generated variable to override the weak symbol of
the same name inside the profile runtime, but using LinkOnceODRLinkage
results in weak symbol being emitted which leads to an issue where the
linker might choose either of the weak symbols potentially disabling the
runtime counter relocation.
This change replaces the use of weak definition inside the runtime with
an external weak reference to address the issue. We also place the
compiler generated symbol inside a COMDAT group so dead definition can
be garbage collected by the linker.
Differential Revision: https://reviews.llvm.org/D105176
If we get here from reallocate, BlockEnd is tagged. Then we
will storeTag(UntaggedEnd) into the header of the next chunk.
Luckily header tag is 0 so unpatched code still works.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D105261
It's already covered by multiple tests, but to trigger
this path we need MTE+GWP which disabled.
Reviewed By: hctim, pcc
Differential Revision: https://reviews.llvm.org/D105232
This allows application code checks if origin tracking is on before
printing out traces.
-dfsan-track-origins can be 0,1,2.
The current code only distinguishes 1 and 2 in compile time, but not at runtime.
Made runtime distinguish 1 and 2 too.
Reviewed By: browneee
Differential Revision: https://reviews.llvm.org/D105128
Users can call HwasanThreadList::GetRingBufferSize rather than RingBufferSize
to prevent having to do the calculation in RingBufferSize. This will be useful
for Fuchsia where we plan to initialize the stack ring buffer separately from
the rest of thread initialization.
Differential Revision: https://reviews.llvm.org/D104823
A heap or global buffer that is far away from the faulting address is
unlikely to be the cause, especially if there is a potential
use-after-free as well, so we want to show it after the other
causes.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D104781
Install libatomic.a in top level library directory so that compiler can find it in search directories.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D104908
I can't be sure of the cause but I believe these fail
due to to fast unwinding not working on Thumb.
Whatever the case, they have been failing on our bots
for a long time:
https://lab.llvm.org/buildbot/#/builders/170/builds/46
Require fast-unwinder-works for both.
Word on the grapevine was that the committee had some discussion that
ended with unanimous agreement on eliminating relational function pointer comparisons.
We wanted to be bold and just ban all of them cold turkey.
But then we chickened out at the last second and are going for
eliminating just the spaceship overload candidate instead, for now.
See D104680 for reference.
This should be fine and "safe", because the only possible semantic change this
would cause is that overload resolution could possibly be ambiguous if
there was another viable candidate equally as good.
But to save face a little we are going to:
* Issue an "error" for three-way comparisons on function pointers.
But all this is doing really is changing one vague error message,
from an "invalid operands to binary expression" into an
"ordered comparison of function pointers", which sounds more like we mean business.
* Otherwise "warn" that comparing function pointers like that is totally
not cool (unless we are told to keep quiet about this).
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D104892
on arm64e, pointer auth would catch this access violation before asan.
sign the function pointer so pointer auth will ignore this violation and let asan catch it in this test case.
rdar://79652167
Reviewed By: delcypher
Differential Revision: https://reviews.llvm.org/D104828
The comment says it was flaky in 2016,
but it wasn't possible to debug it back then.
Re-enable the test at least on linux/x86_64.
It will either work, or at least we should
see failure output from lit today.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D104592
Mmap interceptor is not atomic in the sense that it
exposes unmapped shadow for a brief period of time.
This breaks programs that mmap over another mmap
and access the region concurrently.
Don't unmap shadow in the mmap interceptor to fix this.
Just mapping new shadow on top should be enough to zero it.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D104593
Similar to InitOptions in asan, we can use this optional struct for
initializing some members thread objects before they are created. On
linux, this is unused and can remain undefined. On fuchsia, this will
just be the stack bounds.
Differential Revision: https://reviews.llvm.org/D104553
Bionic <malloc.h> may provide the definitions of M_MEMTAG_TUNING_* constants.
Do not redefine them in that case.
Differential Revision: https://reviews.llvm.org/D104758
This reverts commit 21c008d5a5 since
it broke the build on macOS and Windows with the following error:
The install of the clang_rt.<na,e> target requires changing an
RPATH from the build tree, but this is not supported with the Ninja
generator unless on an ELF-based platform. The
CMAKE_BUILD_WITH_INSTALL_RPATH variable may be set to avoid this relinking
step.
We want to disable the use of undefined symbols on Fuchsia, but there
are cases where it might be desirable so may it configurable.
Differential Revision: https://reviews.llvm.org/D104728
This reverts commit ed7086ad46.
This reverts commit b9792638b0.
This breaks cmake with message:
CMake Error at llvm-project/compiler-rt/CMakeLists.txt:449:
Parse error. Expected "(", got newline with text "
We want to disable the use of undefined symbols on Fuchsia, but there
are cases where it might be desirable so may it configurable.
Differential Revision: https://reviews.llvm.org/D104728
These have been broken by https://reviews.llvm.org/D104494.
However, `lib/fuzzer/dataflow/` is unused (?) so addressing this is not a priority.
Added TODOs to re-enable them in the future.
Reviewed By: stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D104568
Once D104553 lands, CreateCurrentThread will be able to accept optional
parameters for initializing the hwasan thread object. On fuchsia, we can get
stack info in the platform-specific InitThreads and pass it through
CreateCurrentThread. On linux, this is a no-op.
Differential Revision: https://reviews.llvm.org/D104561
These other platforms are unsupported and untested.
They could be re-added later based on MSan code.
Reviewed By: gbalats, stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D104481
Explain what the given stack trace means before showing it, rather than
only in the paragraph at the end.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D104523
This allows for other implementations to define their own version of `Thread::Init`.
This will be the case for Fuchsia where much of the thread initialization can be
broken up between different thread hooks (`__sanitizer_before_thread_create_hook`,
`__sanitizer_thread_create_hook`, `__sanitizer_thread_start_hook`). Namely, setting
up the heap ring buffer and stack info and can be setup before thread creation.
The stack ring buffer can also be setup before thread creation, but storing it into
`__hwasan_tls` can only be done on the thread start hook since it's only then we
can access `__hwasan_tls` for that thread correctly.
Differential Revision: https://reviews.llvm.org/D104248
The default callback instrumentation in x86 LAM mode uses ASLR bits
to randomly choose a tag, and thus has a 1/64 chance of choosing a
stack tag of 0, causing stack tests to fail intermittently. By using
__hwasan_generate_tag to pick tags, we guarantee non-zero tags and
eliminate the test flakiness.
aarch64 doesn't seem to have this problem using thread-local addresses
to pick tags, so perhaps we can remove this workaround once we implement
a similar mechanism for LAM.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D104470
The current naming scheme adds the `dfs$` prefix to all
DFSan-instrumented functions. This breaks mangling and prevents stack
trace printers and other tools from automatically demangling function
names.
This new naming scheme is mangling-compatible, with the `.dfsan`
suffix being a vendor-specific suffix:
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-structure
With this fix, demangling utils would work out-of-the-box.
Reviewed By: stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D104494
These other platforms are unsupported and untested.
They could be re-added later based on MSan code.
Reviewed By: gbalats, stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D104481
This is to fix build on Android. And we don't want to intercept more new/delete operators on Android.
Differential Revision: https://reviews.llvm.org/D104313
Before: ADDR is located -320 bytes to the right of 1072-byte region
After: ADDR is located 752 bytes inside 1072-byte region
Reviewed By: eugenis, walli99
Differential Revision: https://reviews.llvm.org/D104412
Short granule tags as poison cause a UaF to read the referenced
memory to retrieve the tag, and means we do not detect the UaF
if the last granule's tag is still around.
This only increases the change of not catching a UaF from
0.39 % (1 / 256) to 0.42 % (1 / (256 - 17)).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D104304
The dsb after instruction cache invalidation only needs to be executed
if any instruction cache invalidation did happen.
Without this change, if the CTR_EL0.DIC bit indicates that instruction
cache invalidation is not needed, __clear_cache would execute two dsb
instructions in a row; with the second one being unnecessary.
Differential Revision: https://reviews.llvm.org/D104371
The `MockAllocator` used in `ScudoTSDTest` wasn't allocated
properly aligned, which resulted in the `TSDs` of the shared
registry not being aligned either. This lead to some failures
like: https://reviews.llvm.org/D103119#2822008
This changes how the `MockAllocator` is allocated, same as
Vitaly did in the combined tests, properly aligning it, which
results in the `TSDs` being aligned as well.
Add a `DCHECK` in the shared registry to check that it is.
Differential Revision: https://reviews.llvm.org/D104402
Similar to SHADOW_OFFSET on asan, we can use this for hwasan so platforms that
use a constant value for the start of shadow memory can just use the constant
rather than access a global.
Differential Revision: https://reviews.llvm.org/D104275
Apparently __builtin_abort() is not supported when targetting Windows.
This should fix the following builder errors:
clang_rt.builtins-x86_64.lib(int_util.c.obj) : error LNK2019: unresolved
external symbol __builtin_abort referenced in function __compilerrt_abort_impl
When compiled with -ffreestanding, we should not assume that headers
declaring functions such as abort() are available. While the compiler may
still emit calls to those functions [1], we should not require the headers
to build compiler-rt since that can result in a cyclic dependency graph:
The compiler-rt functions might be required to build libc.so, but the libc
headers such as stdlib.h might only be available once libc has been built.
[1] From https://gcc.gnu.org/onlinedocs/gcc/Standards.html:
GCC requires the freestanding environment provide memcpy, memmove,
memset and memcmp. Finally, if __builtin_trap is used, and the target
does not implement the trap pattern, then GCC emits a call to abort.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D103876
cstddef is needed for size_t definition.
(Multiple headers can provide size_t but none of them exists.)
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D96213
This will simplify integration of this code into LLVM -- The
Simple-Packed-Serialization code can be copied near-verbatim, but
WrapperFunctionResult will require more adaptation.
cmake-3.16+ for AIX changes the default behavior of building a `SHARED` library which breaks AIX's build of libatomic, i.e., cmake-3.16+ builds `SHARED` as an archive of dynamic libraries. To fix it, we have to build `libatomic.so.1` as `MODULE` which keeps `libatomic.so.1` as an normal dynamic library.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D103786
Currently, the compiler-rt build system checks only whether __X86_64
is defined to determine whether the default compiler-rt target arch
is x86_64. Since x32 defines __X86_64 as well, we must also check that
the default pointer size is eight bytes and not four bytes to properly
detect a 64-bit x86_64 compiler-rt default target arch.
Reviewed By: hvdijk, vitalybuka
Differential Revision: https://reviews.llvm.org/D99988
Adds the basic instrumentation needed for stack tagging.
Currently does not support stack short granules or TLS stack histories,
since a different code path is followed for the callback instrumentation
we use.
We may simply wait to support these two features until we switch to
a custom calling convention.
Patch By: xiangzhangllvm, morehouse
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D102901
This mostly follows LLVM's InstrProfReader.cpp error handling.
Previously, attempting to merge corrupted profile data would result in
crashes. See https://crbug.com/1216811#c4.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D104050
This fixes an issue introduced by https://reviews.llvm.org/D70662
Function-scope static initialization are guarded in C++, so we should probably
not use it because it introduces a dependency on __cxa_guard* symbols.
In the context of clang, libasan is linked statically, and it currently needs to
the odd situation where compiling C code with clang and asan requires -lstdc++
Differential Revision: https://reviews.llvm.org/D102475
trusty.cpp and trusty.h define Trusty implementations of map and other
platform-specific functions. In addition to adding Trusty configurations
in allocator_config.h and size_class_map.h, MapSizeIncrement and
PrimaryEnableRandomOffset are added as configurable options in
allocator_config.h.
Background on Trusty: https://source.android.com/security/trusty
Differential Revision: https://reviews.llvm.org/D103578
This removes the `__sanitizer_*` allocation function definitions from
`hwasan_interceptors.cpp` and moves them into their own file. This way
implementations that do not use interceptors at all can just ignore
(almost) everything in `hwasan_interceptors.cpp`.
Also remove some unused headers in `hwasan_interceptors.cpp` after the move.
Differential Revision: https://reviews.llvm.org/D103564
In the interests of disabling misc-no-recursion across LLVM (this seems
like a stylistic choice that is not consistent with LLVM's
style/development approach) this NFC preliminary change adjusts all the
.clang-tidy files to inherit from their parents as much as possible.
This change specifically preserves all the quirks of the current configs
in order to make it easier to review as NFC.
I validatad the change is NFC as follows:
for X in `cat ../files.txt`;
do
mkdir -p ../tmp/$(dirname $X)
touch $(dirname $X)/blaikie.cpp
clang-tidy -dump-config $(dirname $X)/blaikie.cpp > ../tmp/$(dirname $X)/after
rm $(dirname $X)/blaikie.cpp
done
(similarly for the "before" state, without this patch applied)
for X in `cat ../files.txt`;
do
echo $X
diff \
../tmp/$(dirname $X)/before \
<(cat ../tmp/$(dirname $X)/after \
| sed -e "s/,readability-identifier-naming\(.*\),-readability-identifier-naming/\1/" \
| sed -e "s/,-llvm-include-order\(.*\),llvm-include-order/\1/" \
| sed -e "s/,-misc-no-recursion\(.*\),misc-no-recursion/\1/" \
| sed -e "s/,-clang-diagnostic-\*\(.*\),clang-diagnostic-\*/\1/")
done
(using sed to strip some add/remove pairs to reduce the diff and make it easier to read)
The resulting report is:
.clang-tidy
clang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming,-misc-no-recursion'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-misc-no-recursion'
compiler-rt/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,-llvm-header-guard,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-header-guard'
flang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,-llvm-include-order,misc-*,-misc-no-recursion,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-include-order,-misc-no-recursion'
flang/include/flang/Lower/.clang-tidy
flang/include/flang/Optimizer/.clang-tidy
flang/lib/Lower/.clang-tidy
flang/lib/Optimizer/.clang-tidy
lld/.clang-tidy
lldb/.clang-tidy
llvm/tools/split-file/.clang-tidy
mlir/.clang-tidy
The `clang/.clang-tidy` change is a no-op, disabling an option that was never enabled.
The compiler-rt and flang changes are no-op reorderings of the same flags.
(side note, the .clang-tidy file in parallel-libs is broken and crashes
clang-tidy because it uses "lowerCase" as the style instead of "lower_case" -
so I'll deal with that separately)
Differential Revision: https://reviews.llvm.org/D103842
Complete support for fast8:
- amend shadow size and mapping in runtime
- remove fast16 mode and -dfsan-fast-16-labels flag
- remove legacy mode and make fast8 mode the default
- remove dfsan-fast-8-labels flag
- remove functions in dfsan interface only applicable to legacy
- remove legacy-related instrumentation code and tests
- update documentation.
Reviewed By: stephan.yichao.zhao, browneee
Differential Revision: https://reviews.llvm.org/D103745
dfsan does not use sanitizer allocator as others. In practice,
we let it use glibc's allocator since tcmalloc needs more work
to be working with dfsan well. With glibc, we observe large
memory leakage. This could relate to two things:
1) glibc allocator has limitation: for example, tcmalloc can reduce memory footprint 2x easily
2) glibc may call unmmap directly as an internal system call by using system call number. so DFSan has no way to release shadow spaces for those unmmap.
Using sanitizer allocator addresses the above issues
1) its memory management is close to tcmalloc
2) we can register callback when sanitizer allocator calls unmmap, so dfsan can release shadow spaces correctly.
Our experiment with internal server-based application proved that with the change, in a-few-day run, memory usage leakage is close to what tcmalloc does w/o dfsan.
This change mainly follows MSan's code.
1) define allocator callbacks at dfsan_allocator.h|cpp
2) mark allocator APIs to be discard
3) intercept allocator APIs
4) make dfsan_set_label consistent with MSan's SetShadow when setting 0 labels, define dfsan_release_meta_memory when unmap is called
5) add flags about whether zeroing memory after malloc/free. dfsan works at byte-level, so bit-level oparations can cause reading undefined shadow. See D96842. zeroing memory after malloc helps this. About zeroing after free, reading after free is definitely UB, but if user code does so, it is hard to debug an overtainting caused by this w/o running MSan. So we add the flag to help debugging.
This change will be split to small changes for review. Before that, a question is
"this code shares a lot of with MSan, for example, dfsan_allocator.* and dfsan_new_delete.*.
Does it make sense to unify the code at sanitizer_common? will that introduce some
maintenance issue?"
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D101204
This resolves an issue tripping a `DCHECK`, as I was checking for the
capacity and not the size. We don't need to 0-init the Vector as it's
done already, and make sure we only 0-out the string on clear if it's
not empty.
Differential Revision: https://reviews.llvm.org/D103716
Leonard Chan