This moves memintrinsic interceptors (memcpy/memmove/memset) into a new
file sanitizer_common_interceptors_memintrinsics.inc.
This is in preparation of redefining builtins, however, we must be
careful to not redefine builtins in TUs that define interceptors of the
same name.
In all cases except for MSan, memintrinsic interceptors were moved to a
new TU $tool_interceptors_memintrinsics.cpp. In the case of MSan, it
turns out this is not yet necessary (as shown by the later patch
introducing memcpy tests).
NFC.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D151552
With -ftrivial-auto-var-init, do not emit memset() calls for performance
critical stack variables.
Reviewed By: vitalybuka, dvyukov, MaskRay
Differential Revision: https://reviews.llvm.org/D151551
The picolib/newlib implementation of scalbn gives slightly different
results compared to glibc and compiler-rt's inlined
__compiler_rt_scalbn in certain rounding modes. Since these tests
are already disabled for msvc which doesn't respect the mode change,
this patch skips them for newlib as well.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D150280
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes#62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
This patch implements `__hwasan_memset_match_all`, `__hwasan_memcpy_match_all` and `__hwasan_memmove_match_all`, making hwasan-match-all-tag flag working for hwasan versions of memset, memcpy and memmove.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D149943
Currently, hwasan-match-all-tag flag is supported in inline memory access instrumentation and outline memory access instrumentation, but not supported in callback memory access instrumentation.
- For inline memory access instrumentation: a hwasan-match-all-tag check is added following the tag-mismtach check, if tag from pointer is mismatched with tag from shadow memory and tag from pointer is not equal with hwasan-match-all-tag, then a tag-mismatch will be report.
- For outline memory acess instrumentation: MatchAllTag is encoded in AccessInfo, when emit HWASAN memaccess symbols, asm-printer emits assembly instructions to check if tag from pointer is equal with hwasan-match-all-tag.
- For callback memory access instrumentation: hwasan-match-all-tag check is not implemented in `__hwasan_load`/`__hwasan_store`.
This patch implements a set of callback functions: `__hwasan_[load|store][1|2|4|8|16|n]_match_all` and `__hwasan_load[load|store][1|2|4|8|16|n]_match_all_noabort`, making hwasan-match-all-tag flag working for callback memory access instrumentation.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D149580
This enables HWASan interception for mmap, to prevent users from allocating in the shadow memory regions. For compatibility, it does not use pointer tagging, nor does it allow MAP_FIXED with a tagged address.
This patch initializes the common interceptors, but that should be a no-op (except for the mmap interceptor), due to the disable-by-default nature of hwasan_platform_interceptors.h (from D150708). As the first patch to utilize this common interceptor machinery for HWASan, it also defines some macros (e.g., COMMON_INTERCEPT_FUNCTION) that will be useful as future interceptors are enabled.
TestCases/Posix/mmap_write_exec.cpp now passes for HWASan.
Reviewed By: kstoimenov, vitalybuka
Differential Revision: D151262
Don't hard code the page in FuzzerUtil.h, this breaks on
e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140607
This reverts commit a2b677e8153758997a9043360cf51333eecc3c44.
reverting
Differential Revision: https://reviews.llvm.org/D140607
because <sys/auxv.h> and getauxval() are not available on macOS;
this change is breaking the mac CI bots.
The primary motivation for this change is to allow FreeHooks to obtain
the allocated size of the pointer being freed in a fast, efficient manner.
Differential Revision: https://reviews.llvm.org/D151360
Don't hard code the page in FuzzerUtil.h, this breaks on
e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140607
LLVM_ENABLE_ZLIB is set to On by default and does not imply that ZLIB
was actually found, only being set to FORCE_ON would imply that it was
found before control reached compiler-rt/test/CMakeLists.txt. Instead,
use ZLIB_FOUND which guarantees that zlib is available.
Differential Revision: https://reviews.llvm.org/D151229
PageMap is allocated with MAP_ALLOWNOMEM if there's no static buffer
left. So it can be failed and return nullptr without any assertion
triggered. Instead of crashing in the releaseToOSMaybe in the middle,
just return and let the program handles the page failure.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D151379
RenderFrame() has several implementations, which was missed in
01cea39f8e11012ac96b36ef60bfaf2f3b64320b.
Fix the one in sanitizer_symbolizer_markup.cpp.
Reported-by: gulfem
# Darwin Sanitizers Stable ABI
We wish to make it possible to include the AddressSanitizer (ASan) runtime implementation in OSes and for this we need a stable ASan ABI. Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms. Therefore, we propose adding a secondary stable ABI for our use and anyone else in the community seeking the same. We believe that we can define a stable ABI with minimal burden on the community, expecting only to keep existing tests running and implementing stubs when new features are added. We are okay with trading performance for stability with no impact for existing users of ASan while minimizing the maintenance burden for ASan maintainers. We wish to commit this functionality to the LLVM project to maintain it there. This new and stable ABI will abstract away the implementation details allowing new and novel approaches to ASan for developers, researchers and others.
## Details
Rather than adding a lot of conditional code to the LLVM instrumentation phase, which would incur excessive complexity and maintenance cost of adding conditional code into all places that emit a runtime call, we propose a “shim” layer which will map the unstable ABI to the stable ABI:
* A static library (.a library) shim that maps the existing ASan ABI to a generalized, smaller and stable ABI. The library would implement the __asan functions and call into the new ABI. For example:
* `void __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); }`
* `void __asan_load2(uptr p) { __asan_abi_loadn(p, 2, true); }`
* `void __asan_noabort_load16(uptr p) { __asan_abi_loadn(p, 16, false); }`
* `void __asan_poison_cxx_array_cookie(uptr p) { __asan_abi_pac(p); }`
* This “shim” library would only be used by people who opt in: A compilation flag in the Clang driver will be used to gate the use of the stable ABI workflow.
* Utilize the existing ability for the ASan instrumentation to prefer runtime calls instead of inlined direct shadow memory accesses.
* Pursue (under the new driver flag) a better separation of abstraction and implementation with:
* LLVM instrumentation: Calling out for all poisoning, checking and unpoisoning.
* Runtime: Implementing the stable ABI and being responsible of implementation details of the shadow memory.
## Maintenance
Our aim is that the maintenance burden on the sanitizer developer community be negligible. Stable ABI tests will always pass for non-Darwin platforms. Changes to the existing ABI which would require a change to the shim have been infrequent as the ASan ABI is already relatively stable. Rarely, a change that impacts the contract between LLVM and the shim will occur. Among such foreseeable changes are: 1) changes to a function signature, 2) additions of new functions, or 3) deprecation of an existing function. Following are some examples of reasonable responses to those changes:
* Example: An existing ABI function is changed to return the input parameter on success or NULL on failure. In this scenario, a reasonable change to the shim would be to modify the function signature appropriately and to simply guess at a common-sense implementation.
* `uptr __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); return p; }`
* Example: An additional function is added for performance reasons. It has a very similar function signature to other similarly named functions and logically is an extension of that same pattern. In this case it would make sense to apply the same logic as the existing entry points:
* `void __asan_load128(uptr p) { __asan_abi_loadn(p, 128, true); }`
* Example: An entry point is added to the existing ABI for which there is no obvious stable ABI implementation: In this case, doing nothing in a no-op stub would be acceptable, assuming existing features of ASan can still work without an actual implementation of this new function.
* `void __asan_prefetch(uptr p) { }`
* Example: An entrypoint in the existing ABI is deprecated and/or deleted:
* (Delete the entrypoint from the shim.)
We’re looking for buy-in for this level of support.
(Note: Upon acceptance of the general concepts herein, we will add a controlling clang flag, cmake integration, contract for the stable ABI, and the appropriate test infrastructure.)
Reviewed By: eugenis, vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D143675
release_to_os has been failing on powerpc64 since yesterday. Temporarily disabling the test to prevent this error from
hiding other potential problems.
Showing __interceptor_ as part of the function name in reports does not
make sense and is distracting.
Strip the interceptor function name before printing.
Reviewed By: dvyukov, vitalybuka
Differential Revision: https://reviews.llvm.org/D151343
Rather than having every tool pass the right interceptor prefix, just
move this logic into RenderFrame().
Note that currently there are a few cases where due to aliasing the
intercepted function -> interceptor, the unwinder sees the intercepted
function - however this is never guaranteed. In a later change this
becomes more apparent, and other non-tsan sanitizer tests would fail as
well. By making the default RenderFrame() strip interceptor prefixes, we
don't rely on the linker aliasing preferences.
Reviewed By: dvyukov, vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D151319
The Linux and *BSD interceptors are almost identical, except for *BSD,
where the overridden intercepted function is not defined weak due to
some incompliant linker behaviour.
Since most of the interception machinery is shared between Linux and
*BSD (see INTERCEPT_FUNCTION macro), it makes sense to unify interceptor
definition and declarations as much as possible to ease future changes.
NFC.
Reviewed By: dvyukov, vitalybuka
Differential Revision: https://reviews.llvm.org/D151318
This introduces macros for asm sources to define trampolines, and
aliases to trampolines.
Because we currently do not yet have any real trampolines, this change
is a NFC.
Reviewed By: dvyukov, vitalybuka
Differential Revision: https://reviews.llvm.org/D151317
To make the interceptor implementation more flexible, allowing for 2
levels of indirection instead of just 1 in the current scheme (where the
intercepted function aliases the interceptor implementation), introduce
the notion of an interceptor "trampoline".
A trampoline may be a real function (and not just an alias, where
aliases of aliases do not work), which will simply forward to the
interceptor implementation; the intercepted function will then alias the
trampoline:
func -[alias]-> trampoline -[call]-> interceptor
Make the necessary changes to prepare for introducing real trampolines.
This change does not yet introduce any real trampolines, and so
trampoline == interceptor, and we currently still just have:
func -[alias]-> interceptor
NFC.
Reviewed By: dvyukov, vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D151316
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
This has been causing substantial redness in the buildbots e.g.,
https://lab.llvm.org/buildbot/#/builders/239/builds/2405
which already contained a commit to deflake the test
(3afd1b2c35).
Temporarily disabling the test to prevent this error from
hiding other potential problems.
__sanitizer_get_current_allocated_bytes had as body, but allocator
caches were not registered to collect stats. It's done by
SizeClassAllocator64LocalCache::Init().
Reviewed By: thurston
Differential Revision: https://reviews.llvm.org/D151389
Currently, the header file contains all the undefs, followed by all the
define X 0. This will be inconvenient for re-enabling interceptors,
because we would need to comment out (or delete) the corresponding macros
in two different places.
This patch groups together the macros for each function.
Additionally, it adds the suggestion that interceptors should be
re-enabled by commenting out (not deleting) the macros.
Differential Revision: https://reviews.llvm.org/D151371
