Fixes asan, msan crash on check added in #108684.
The #108684 includes reproducer of the issue.
Change interface of `GetThreadStackAndTls` to
set `tls_begin` and `tls_end` at the same time.
`DTLS_on_libc_memalign` is called from primary
allocator, so `__sanitizer_get_allocated_begin`
should also be aware of allocation,
and correctly handled by `GetDTLSRange`.
C++11 `alignas` is already used extensively. `alignas` must precede
`static`, so adjust the ordering accordingly.
msan.cpp: Clang 15 doesn't allow `__attribute__((visibility("default"))) alignas(16)`.
Use the order `alignas(16) SANITIZER_INTERFACE_ATTRIBUTE`. Tested with Clang 7.
Pull Request: https://github.com/llvm/llvm-project/pull/98958
We already have `const uptr kMaxAllowedMallocSize = 1ULL << 40;` set for
ASAN, HWASAN, memprof, TSAN. This patch bumps the malloc limit for MSAN,
LSAN and DFSAN to 1TB as well. 8GB is simply not enough nowadays.
The MSG_TRUNC flag makes recvmsg return the real length of the packet,
even if it was too big to fit in the provided buffer. This is commonly
used together with MSG_PEEK.
Without this patch, dfsan's clear_msghdr_labels expects the return value
of recvmsg (size recieved) to be less than or equal to the iov buffer
length where recvmsg writes data, resulting in a crash.
DFSan's shadow mappings are incompatible with 32 bits of ASLR entropy
('sudo sysctl vm.mmap_rnd_bits=32; ninja check-dfsan') and it is
difficult to fix this via increasing the size of the shadow mappings,
due to the overhead of shadow memory. This patch works around the issue
by detecting if the memory layout is incompatible, and if so,
re-exec'ing without ASLR.
DFSan and MSan share copy-pasted shadow memory code, hence this
workaround is ported from MSan:
- "[msan] Re-exec with no ASLR if memory layout is incompatible on
Linux"
(58f7251820)
- "[msan] Add 'MappingDesc::ALLOCATOR' type and check it is available"
(af2bf86a37)
(which in turn are inspired by TSan: "Re-exec TSan with no ASLR if
memory layout is incompatible on Linux"
(0784b1eefa
))
aeubanks had remarked in
https://github.com/llvm/llvm-project/pull/85142#issuecomment-2004442883
that this issue occurs in Chromium:
https://ci.chromium.org/ui/p/chromium/builders/try/linux_upload_clang/5066/overview
Fix#79283: `test/dfsan/custom.cpp` has undefined symbol linker errors
on glibc 2.38 due to lack of wrappers for `__isoc23_strtol` and
`__isoc23_scanf` family functions.
Implement these wrappers as aliases to existing wrappers, similar to
https://reviews.llvm.org/D158943 for other sanitizers.
`strtol` in a user program, whether or not `_ISOC2X_SOURCE` is defined,
uses the C23 semantics (`strtol("0b1", 0, 0)` => 1), when
`libclang_rt.dfsan.a` is built on glibc 2.38+.
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.
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 is preparation for performance optimization.
We need to highlight that this is very specific lock, and should not be
used for other purposes.
Add `fork_child` parameter to distinguish processes after fork.
/data/llvm-project/compiler-rt/lib/dfsan/dfsan_custom.cpp:2546:37: error: parameter 'va_labels' set but not used [-Werror,-Wunused-but-set-parameter]
dfsan_label *va_labels, dfsan_label *ret_label,
^
1 error generated.
__sanitizer_get_allocated_begin and __sanitizer_get_allocated_size_fast
were introduced recently in D147005 and D151360, but not added here,
leading to linker errors.
Differential Revision: https://reviews.llvm.org/D153680
I noticed that in some cases _tolower shows as uninstrumented - I've added it as "functional" in the done_abilist.txt file
Reviewed by: browneee
Differential Revision: https://reviews.llvm.org/D153410
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
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
D147005 introduced __sanitizer_get_allocated_begin, with a return
value of void*. This involved a few naughty casts that dropped the
const. This patch adds back the const qualifier.
Differential Revision: https://reviews.llvm.org/D147489
I found a few Python files not using Python 3 syntax in the tree
when trying to apply reformatting to them. This was converted with
2to3 and the changes seemed sane.
Reviewed By: MaskRay, browneee
Differential Revision: https://reviews.llvm.org/D143701
compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake:ALL_DFSAN_SUPPORTED_ARCH
allows AArch64 but currently the instrumentation will crash.
Port Linux AArch64 memory mappings from msan but use
SizeClassAllocator64 for a slightly more efficient allocator (used by
asan/lsan). Change dfsan/lit.cfg.py to allow Linux aarch64. All tests
should pass.
* dfsan/origin_invalid.c uses x86_64 assembly. Just make it x86_64 specific.
* dfsan/interceptors.c our mallinfo interceptor takes an argument
instead of returning a struct. This does not work on AArch64 which
uses different registers for the two function types. Disable AArch64
as msan/Linux/mallinfo.cpp does.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140770
