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
__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/D151355
This is a very simple test that calls wsclen. There are currently no other HWASan tests that call wsclen, which is why the wcslen interceptor issue (triggered by https://reviews.llvm.org/D150708 and fixed in https://reviews.llvm.org/D150909) was only detected by stage2/hwasan check on the buildbots. With this test, the issue would have been caught by stage1 check-sanitizer, with a more obvious diagnosis.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D151000
__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: kstoimenov
Differential Revision: https://reviews.llvm.org/D151352
Do not open code creation of an interceptor alias to another
interceptor. Instead, use INTERCEPTOR() + ALIAS() + WRAP.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D151219
The __interceptor_*setjmp() definitions appear to have been defined for
the purpose of TSAN_INTERCEPT(), but on non-Mac systems, it seems
TSAN_INTERCEPT() isn't even being used anymore for setjmp.
Remove them. Nothing should call them anyway (due to CHECK-fail), so
having the linker fail is better than failing at runtime.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D151218
Use ASM_WRAPPER_NAME to produce the name of the __interceptor_*
functions.
NFC.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D151217
Most uses of ALIAS() are in conjunction with WRAPPER_NAME().
Simplify the code and just make ALIAS() turn its argument into a string
(similar to Linux kernel's __alias macro). This in turn allows removing
WRAPPER_NAME().
NFC.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D151216
This way, Fuchsia can use the 64-bit allocator settings in D151157 without changing the default behavior for others.
Differential Revision: https://reviews.llvm.org/D151159
This patch does the bare minimum to import sanitizer_common_interceptors, but
without actually enabling any interceptors or meaningfully defining the
COMMON_INTERCEPT macros.
This will allow selectively enabling sanitizer_common interceptors (if the
appropriate macros are defined), as suggested by Vitaly in D149701.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D150708
Ensures a subsequent call (via an external caller) to
__sanitizer_get_allocated_size via hooks will return a valid size.
This allows a faster version of __sanitizer_get_allocated_size
to be implemented, which can skip checks.
Test to ensure RunFreeHooks' call order will come with
__sanitizer_get_allocated_size_fast
Differential Revision: https://reviews.llvm.org/D151151
Previously lsan would not invoke hooks on reallocations.
An accompanying regression test is included in sanitizer_common.
This change also moves hook calls to a location where subsequent
calls (via an external caller) to __sanitizer_get_allocated_size
via hooks will return a valid size.
This allows a faster version of __sanitizer_get_allocated_size
to be implemented, which can skip checks.
Test to ensure RunFreeHooks' call order will come with
__sanitizer_get_allocated_size_fast
Differential Revision: https://reviews.llvm.org/D151175
With D148785, -fsanitize=function no longer uses C++ RTTI objects and therefore
can support C. The rationale for reporting errors is C11 6.5.2.2p9:
> If the function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function, the behavior is undefined.
The mangled types approach we use does not exactly match the C type
compatibility (see `f(callee1)` below).
This is probably fine as the rules are unlikely leveraged in practice. In
addition, the call is warned by -Wincompatible-function-pointer-types-strict.
```
void callee0(int (*a)[]) {}
void callee1(int (*a)[1]) {}
void f(void (*fp)(int (*)[])) { fp(0); }
int main() {
int a[1];
f(callee0);
f(callee1); // compatible but flagged by -fsanitize=function, -fsanitize=kcfi, and -Wincompatible-function-pointer-types-strict
}
```
Skip indirect call sites of a function type without a prototype to avoid deal
with C11 6.5.2.2p6. -fsanitize=kcfi skips such calls as well.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D148827
ELFObjectWriter.cpp may report
```
error: Cannot represent a difference across sections
```
on some ppc64be configurations, likely related to some interaction
between the obsoleted ELFv1 and MC.
Unfortunately I cannot reproduce this locally with --target=powerpc64-linux-gnu.
The qemu environment cannot run an executable with a link-time shared
object built during the test?
```
Input was:
<<<<<<
1: CANNOT LINK EXECUTABLE "/data/local/tmp/Output/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/ubsan/Standalone-aarch64/TestCases/TypeCheck/Function/Output/function.cpp.tmp": library "/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/ubsan/Standalone-aarch64/TestCases/TypeCheck/Function/Output/function.cpp.tmp-so.so" not found: needed by main executable
```
The emulated environment has a spurious failure that causes many other
tests to XFAIL. Unsupport it for now.
```
1: CANNOT LINK EXECUTABLE "/data/local/tmp/Output/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_arm/test/ubsan/Standalone-arm/TestCases/TypeCheck/Function/Output/function.cpp.tmp": library "/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_arm/test/ubsan/Standalone-arm/TestCases/TypeCheck/Function/Output/function.cpp.tmp-so.so" not found: needed by main executable
```
These are aliases on musl and as of 1.2.4, aren't visible by default
(only with -D_LARGEFILE64_SOURCE), and will be removed entirely in a future
release.
This fixes a runtime failure with msan on musl-1.2.4:
```
$ echo 'int main(){}' | clang -x c - -fsanitize=memory -o /dev/null
/usr/bin/x86_64-gentoo-linux-musl-ld.bfd: /usr/lib/llvm/16/bin/../../../../lib/clang/16/lib/linux/libclang_rt.msan-x86_64.a(msan_interceptors.cpp.o): in function `__interceptor_getrlimit64':
[...]
```
Bug: https://bugs.gentoo.org/906603
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D150925
Currently we use RTTI objects to check type compatibility. To support non-unique
RTTI objects, commit 5745eccef54ddd3caca278d1d292a88b2281528b added a
`checkTypeInfoEquality` string matching to the runtime.
The scheme is inefficient.
```
_Z1fv:
.long 846595819 # jmp
.long .L__llvm_rtti_proxy-_Z3funv
...
main:
...
# Load the second word (pointer to the RTTI object) and dereference it.
movslq 4(%rsi), %rax
movq (%rax,%rsi), %rdx
# Is it the desired typeinfo object?
leaq _ZTIFvvE(%rip), %rax
# If not, call __ubsan_handle_function_type_mismatch_v1, which may recover if checkTypeInfoEquality allows
cmpq %rax, %rdx
jne .LBB1_2
...
.section .data.rel.ro,"aw",@progbits
.p2align 3, 0x0
.L__llvm_rtti_proxy:
.quad _ZTIFvvE
```
Let's replace the indirect `_ZTI` pointer with a type hash similar to
`-fsanitize=kcfi`.
```
_Z1fv:
.long 3238382334
.long 2772461324 # type hash
main:
...
# Load the second word (callee type hash) and check whether it is expected
cmpl $-1522505972, -4(%rax)
# If not, fail: call __ubsan_handle_function_type_mismatch
jne .LBB2_2
```
The RTTI object derives its name from `clang::MangleContext::mangleCXXRTTI`,
which uses `mangleType`. `mangleTypeName` uses `mangleType` as well. So the
type compatibility change is high-fidelity.
Since we no longer need RTTI pointers in
`__ubsan::__ubsan_handle_function_type_mismatch_v1`, let's switch it back to
version 0, the original signature before
e215996a2932ed7c472f4e94dc4345b30fd0c373 (2019).
`__ubsan::__ubsan_handle_function_type_mismatch_abort` is not
recoverable, so we can revert some changes from
e215996a2932ed7c472f4e94dc4345b30fd0c373.
Reviewed By: samitolvanen
Differential Revision: https://reviews.llvm.org/D148785
It shouldn't be assumed that libstdc++ is always available even on Linux.
Just let the compiler pick the default
Differential Revision: https://reviews.llvm.org/D150809
