This is clearly a copy-paste mistake, fix it with this patch.
After checking the `local.function_name` is not null, it should check
the len for `local.function_name`, not `local.name`. And this could lead
to possible null dereference since the second
`internal_strlen(local.name)` does not guarantee `local.name` is not
null.
TSan's shadow mappings only support 30-bits of ASLR entropy on x86
Linux, and it is not practical to support the maximum of 32-bits (due to pointer compression and the overhead of shadow mappings). Instead, this patch changes TSan to re-exec without ASLR if it encounters an
incompatible memory layout, as suggested by Dmitry in
https://github.com/google/sanitizers/issues/1716.
If ASLR is already disabled but the memory layout is still incompatible,
it will abort.
This patch involves a bit of refactoring, because the old code is:
1. InitializePlatformEarly()
2. InitializeAllocator()
3. InitializePlatform(): CheckAndProtect()
but it may already segfault during InitializeAllocator() if the memory
layout is incompatible, before we get a chance to check in
CheckAndProtect().
This patch adds CheckAndProtect() during InitializePlatformEarly(), before the allocator is initialized. Naturally, it is necessary to ensure that CheckAndProtect() does *not* allow the heap regions to be occupied here, hence we generalize CheckAndProtect() to optionally check the heap
regions. We keep the original behavior of CheckAndProtect() in InitializePlatform() as a last line of defense.
We need to be careful not to prematurely abort if ASLR is disabled but TSan was going to re-exec for other reasons (e.g., unlimited stack size); we implement this by moving all the re-exec logic into ReExecIfNeeded().
Mark the following symbols as `static` to prevent duplicate definitions:
`__builtin_ctz`
`__builtin_clz`
`__builtin_clzll`
`__builtin_sadd_overflow`
>Without these then all of these functions show up in all object files
which include int_lib.h on Windows. This'll help prevent duplicate
symbols by ensuring they're not exported.
See:
https://github.com/rust-lang/compiler-builtins/issues/167https://reviews.llvm.org/D34599
The test fails on Darwin, see comment on the PR.
> std:: usually is not a cause of the bug.
>
> We now display
> ```
> SUMMARY: AddressSanitizer: allocation-size-too-big path/to/allocator_returns_null.cpp:92:7 in main
> ```
> instead of
>
> ```
> SUMMARY: AddressSanitizer: allocation-size-too-big /usr/lib/../include/c++/13/bits/new_allocator.h:147:27 in std::__new_allocator<char>::allocate(unsigned long, void const*)
> ```
>
> `/include/c++/` matches both libc++ and libstdc++ include paths.
This reverts commit ecd47811b755d13357085bcd7519a66d6c4d8e5c.
The test (from https://reviews.llvm.org/D7098) is about the interaction
of VLA and alloca where the VLA causes alloca to have the same address.
This is mostly about behavior checking and less about instrumentation
correctness, so I think it is fair to disable it for a platform that
does not work after StackSafetyAnalysis is enabled by default (#77210).
For Windows, the compiler-rt profile library contains a polyfill
reimplementation of the mmap family of functions.
Previously, the runtime library exposed those symbols like, "mmap", in
the user symbol namespace. This could cause misdetections by configure
scripts that check for the "mmap" function just by linking, without
including headers.
Add a prefix on the symbols, and make an undeclared function static.
This fixes such an issue reported at
https://github.com/mstorsjo/llvm-mingw/issues/390.
This ports msan https://reviews.llvm.org/D14795 to dfsan.
dfsan, like msan, clears shadow for globals in a newly opened DSO in
case the DSO occupies the address of a previously labeled/poisoned area.
The operation should not happen on the main executable.
In addition, for a DT_EXEC executable, l_addr is zero and will lead to a
null pointer dereference in ForEachMappedRegion.
std:: usually is not a cause of the bug.
We now display
```
SUMMARY: AddressSanitizer: allocation-size-too-big path/to/allocator_returns_null.cpp:92:7 in main
```
instead of
```
SUMMARY: AddressSanitizer: allocation-size-too-big /usr/lib/../include/c++/13/bits/new_allocator.h:147:27 in std::__new_allocator<char>::allocate(unsigned long, void const*)
```
`/include/c++/` matches both libc++ and libstdc++ include paths.
explicitly pass libLTO path. This fixes a failure in swift-ci where
libLTO was being picked from the system instead which was an older
version and caused issues.
rdar://117474861
snprintf interceptors call `format_buffer` with `size==~0ul`, which
may eventually lead to `snprintf(s, n, "Hello world!")` where `s+n`
wraps around. Since glibc 2.37 (https://sourceware.org/PR30441), the
snprintf call does not write the last char. musl snprintf returns -1
with EOVERFLOW when `n > INT_MAX`.
Change `size` to INT_MAX to work with glibc 2.37+ and musl.
snprintf interceptors are not changed. It's user responsibility to not
cause a compatibility issue with libc implementations.
Fix#60678
This fixes:
```
[3334/7449] Building C object projects\compiler-rt\lib\builtins\CMakeFiles\clang_rt.builtins-x86_64.dir\extendsfdf2.c.obj
C:\git\llvm-project\compiler-rt\lib\builtins\fp_extend_impl.inc(63): warning C4018: '<': signed/unsigned mismatch
```
This fixes (the ORC lib already builds with exceptions disabled):
```
[5/11] Building CXX object projects\compiler-rt\lib\orc\CMakeFiles\RTOrc.x86_64.dir\dlfcn_wrapper.cpp.obj
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\vector(1619): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
```
This fixes several of these:
```
[3524/7446] Building CXX object projects\compiler-rt\lib\orc\CMakeFiles\RTOrc.x86_64.dir\dlfcn_wrapper.cpp.obj
In file included from C:\git\llvm-project\compiler-rt\lib\orc\dlfcn_wrapper.cpp:15:
C:\git\llvm-project\compiler-rt\lib\orc\wrapper_function_utils.h(299,27): warning: address of '__orc_rt_jit_dispatch_ctx' will always evaluate to 'true' [-Wpointer-bool-conversion]
299 | if (ORC_RT_UNLIKELY(!&__orc_rt_jit_dispatch_ctx))
| ~ ^~~~~~~~~~~~~~~~~~~~~~~~~
C:\git\llvm-project\compiler-rt\lib\orc\compiler.h(60,55): note: expanded from macro 'ORC_RT_UNLIKELY'
60 | #define ORC_RT_UNLIKELY(EXPR) __builtin_expect((bool)(EXPR), false)
| ^~~~
1 warning generated.
```
This fixes:
```
C:\git\llvm-project\compiler-rt\lib\orc\coff_platform.cpp(512): warning C4189: 'JDState': local variable is initialized but not referenced
```
Currently, almost all of the shared libraries of MIPS, rely on $t9
to get the address of current function, instead of PCREL instructions,
even on MIPSr6. So we have to set $t9 properly.
To get the address of preemptible function, we need the help of GOT.
MIPS/O32 has .cpload, which can help to generate 3 instructions to get GOT.
For __mips64, we can get GOT by:
lui $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)))))
daddu $t8, $t8, $t9
daddiu $t8, $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)))))
And then get the address of __interceptor_func, and jump to it
ld $t9, %got_disp(_interceptor" SANITIZER_STRINGIFY(func) ")($t8)
jr $t9
Fixes#74047
Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com>
This variable was explicitly removed from the cache to ease transition
from existing build directories but that breaks passing
COMPILER_RT_BUILD_CRT=OFF on the command line. I was surprised to see
the CRT builds being run for my builtins-only build config (I noticed
because one of the tests was failing despite having `REQUIRES: crt`).
If I pass `-DCOMPILER_RT_BUILD_CRT=OFF` to cmake and add some prints
around the `unset` statement it shows the following:
```
-- before unset(): COMPILER_RT_BUILD_CRT=OFF
-- after unset: COMPILER_RT_BUILD_CRT=
-- after cmake_dependent_option COMPILER_RT_BUILD_CRT=ON
```
Drop this temporary workaround now that over 6 months have passed.
It turns out this works _mostly_ fine, even when mixing debug versions
of asan with programs built with the release runtime. Using /MT (or
/MTd) with a dynamically linked asan has never really worked that well,
and I am planning on opening a PR that will completely remove the
static-asan configuration for windows and make programs linked with the
static CRT/runtime work with the DLL version of asan. This is better
than the current situation because the static linked version of asan
doesn't work well on windows if there are multiple DLLs in the process
using it.
The check for building asan with only /MD or /MT has been removed. It
was in AsanDoesNotSupportStaticLinkage, but was checking for debug CRTs,
not static linkage. The kind of static linkage this function is supposed
to check for (on linux for example) doesn't really exist on windows.
Note: There is one outstanding issue with this approach, if you mix a
/MDd DLLs and /MD dlls in the same process then the "real" function
called by asan interceptors will be the same for calls from both
contexts, potentially screwing up things like errno. This only happens
if you mix /MD and /MDd in the same process, because otherwise asan
won't find functions from both runtimes to intercept. We are working on
a fix for this, and it mainly hits with the CRT functions exported from
both ucrtbase and ntdll.
This change is being upstreamed from Microsoft's fork.
Forward fix for https://github.com/llvm/llvm-project/pull/75256
The process for MmapAlignedOrDieOnFatalError involves trimming the start
and end of a mapping to ensure it's aligned correctly. This invloves
calling zx_vmar_map again but overwriting a part of the original vmar
which involves a call to zx_object_get_info(ZX_INFO_VMAR). After
https://github.com/llvm/llvm-project/pull/75256, we unconditionally
called this on gSanitizerHeapVmar but this can lead to a
ZX_ERR_INVALID_ARGS if the prior mapping was on the root vmar.
This can be fixed by also returning the vmar we did the last mapping to
and using that for followup operations that specifically involve the
same vmar. This way we don't have to try each syscall for both vmars.
https://github.com/llvm/llvm-project/pull/68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support. I added support for QUAD_PRECISION to
use the native hex float long double representation.
---------
Co-authored-by: Alexander Richardson <mail@alexrichardson.me>
In an effort to reduce more mmap fragmentation, allocate a large enough
vmar where we can map sanitizer internals via DoAnonymousMmap. Objects
being mapped here include asan's FakeStack, LowLevelAllocator mappings,
the primary allocator's TwoLevelMap, InternalMmapVector, StackStore, and
asan's thread internals. The vmar is large enough to hold the total size
of these objects seen in a "typical" process lifetime. If the vmar is
full, it will fallback to mapping in the root vmar.
StackSafetyAnalysis determines whether stack-allocated variables are
guaranteed to be safe from memory access bugs and enables the removal of
certain unneeded instrumentations.
(hwasan enables StackSafetyAnalysis in https://reviews.llvm.org/D108381)
In a release build of clang, text sections are 9% smaller.
Test updates:
* asan-stack-safety.ll: test the -asan-use-stack-safety=1 default
* lifetime-uar-uas.ll: switch to an indexed store to prevent
StackSafetyAnalysis from optimizing out instrumentation for %c
* alloca_vla_interact.cpp: add a load to prevent StackSafetyAnalysis
from optimizing out `__asan_alloca_poison` for the VLA `array`
* scariness_score_test.cpp: add -asan-use-stack-safety=0 to make a load
of a `__asan_poison_memory_region`-poisoned local variable fail as
intended.
* other .ll tests: add -asan-use-stack-safety=0
Reviewed By: kstoimenov
Pull Request: https://github.com/llvm/llvm-project/pull/77210
Calling one of pthread join/detach interceptor on an already
joined/detached thread causes asserts such as:
AddressSanitizer: CHECK failed: sanitizer_thread_arg_retval.cpp:56
"((t)) != (0)" (0x0, 0x0) (tid=1236094)
#0 0x555555634f8b in __asan::CheckUnwind()
compiler-rt/lib/asan/asan_rtl.cpp:69:3
#1 0x55555564e06e in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:86:24
#2 0x5555556491df in __sanitizer::ThreadArgRetval::BeforeJoin(unsigned
long) const
compiler-rt/lib/sanitizer_common/sanitizer_thread_arg_retval.cpp:56:3
#3 0x5555556198ed in Join<___interceptor_pthread_tryjoin_np(void*,
void**)::<lambda()> >
compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_arg_retval.h:74:26
#4 0x5555556198ed in pthread_tryjoin_np
compiler-rt/lib/asan/asan_interceptors.cpp:311:29
The assert are replaced by error codes.
StackSafetyAnalysis determines whether stack-allocated variables are
guaranteed to be safe from memory access bugs and enables the removal of
certain unneeded instrumentations.
(hwasan enables StackSafetyAnalysis in https://reviews.llvm.org/D108381)
Test updates:
* asan-stack-safety.ll: test the -asan-use-stack-safety=1 default
* lifetime-uar-uas.ll: switch to an indexed store to prevent
StackSafetyAnalysis from optimizing out instrumentation for %c
* alloca_vla_interact.cpp: add a load to prevent StackSafetyAnalysis
from optimizing out `__asan_alloca_poison` for the VLA `array`
* scariness_score_test.cpp: add -asan-use-stack-safety=0 to make a load
of a `__asan_poison_memory_region`-poisoned local variable fail as
intended.
* other .ll tests: add -asan-use-stack-safety=0
Reviewers: kstoimenov, eugenis, vitalybuka
Reviewed By: kstoimenov
Pull Request: https://github.com/llvm/llvm-project/pull/77210
To enable the condition variable, you have to define both
UseConditionVariable and the ConditionVariableT. Otherwise, it'll be
disabled. However, you may want to disable the condition variable by
setting UseConditionVariable=false, for example, while measuring the
performance and you want to turn it off temporarily. Instead of
requiring the removal of the variable, examining its value makes more
sense.
It is desirable to be able to configure the `-mmacosx-version-min` flag
for the sanitizers, but this flag was never made a CACHE variable in
cmake.
By doing this, it will allow developers to select different minimum
versions, which results in different interceptors being enabled or
disabled on their platforms. This version can now persist between cmake
runs, so it can be remembered by cmake, and edited in the cache file.
This PR exposes four PGO functions
- `__llvm_profile_set_filename`
- `__llvm_profile_reset_counters`,
- `__llvm_profile_dump`
- `__llvm_orderfile_dump`
to user programs through the new header `instr_prof_interface.h` under
`compiler-rt/include/profile`. This way, the user can include the header
`profile/instr_prof_interface.h` to introduce these four names to their
programs.
Additionally, this PR defines macro `__LLVM_INSTR_PROFILE_GENERATE` when
the program is compiled with profile generation, and defines macro
`__LLVM_INSTR_PROFILE_USE` when the program is compiled with profile
use. `__LLVM_INSTR_PROFILE_GENERATE` together with
`instr_prof_interface.h` define the PGO functions only when the program
is compiled with profile generation. When profile generation is off,
these PGO functions are defined away and leave no trace in the user's
program.
Background:
https://discourse.llvm.org/t/pgo-are-the-llvm-profile-functions-stable-c-apis-across-llvm-releases/75832
