It's a new syscall similar to epoll_pwait.
Add a similar interceptor for it and add synchronization
annotations in epoll_wait* syscall wrappers.
Testing this is problematic b/c it's not present in glibc
and the syscall itself may not be supported by the kernel.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D138574
For the RAII lock usage we need to create a local var. There were some headers which clang-tidy identified as unused.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D138593
It broke the build, see comments on code review.
> Leaves the implementation and tests files in-place for right now, but
> deletes the ability to build the old sanitizer-common based scudo. This
> has been on life-support for a long time, and the newer scudo_standalone
> is much better supported and maintained.
>
> Also patches up some GWP-ASan wording, primarily related to the fact
> that -fsanitize=scudo now is scudo_standalone, and therefore the way to
> reference the GWP-ASan options through the environment variable has
> changed.
>
> Future follow-up patches will delete the original scudo, and migrate all
> its tests over to be part of the scudo_standalone test suite.
>
> Reviewed By: vitalybuka
>
> Differential Revision: https://reviews.llvm.org/D138157
This reverts commit ab1a5991fe.
Leaves the implementation and tests files in-place for right now, but
deletes the ability to build the old sanitizer-common based scudo. This
has been on life-support for a long time, and the newer scudo_standalone
is much better supported and maintained.
Also patches up some GWP-ASan wording, primarily related to the fact
that -fsanitize=scudo now is scudo_standalone, and therefore the way to
reference the GWP-ASan options through the environment variable has
changed.
Future follow-up patches will delete the original scudo, and migrate all
its tests over to be part of the scudo_standalone test suite.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D138157
If `pathname` is an empty string and the AT_EMPTY_PATH flag is specified in `flags`,
statx `pathname` argument is of type `const char *restrict`, so it should be `""`
instead of `0`.
Reviewed By: SixWeining, xen0n, xry111, lixing-star
Differential Revision: https://reviews.llvm.org/D138414
This revision is a part of a series of patches extending
AddressSanitizer C++ container overflow detection capabilities by adding
annotations, similar to those existing in std::vector, to std::string
and std::deque collections. These changes allow ASan to detect cases
when the instrumented program accesses memory which is internally
allocated by the collection but is still not in-use (accesses before or
after the stored elements for std::deque, or between the size and
capacity bounds for std::string).
The motivation for the research and those changes was a bug, found by
Trail of Bits, in a real code where an out-of-bounds read could happen
as two strings were compared via a std::equals function that took
iter1_begin, iter1_end, iter2_begin iterators (with a custom comparison
function). When object iter1 was longer than iter2, read out-of-bounds
on iter2 could happen. Container sanitization would detect it.
This revision adds a new compiler-rt ASan sanitization API function
sanitizer_annotate_double_ended_contiguous_container necessary to
sanitize/annotate double ended contiguous containers. Note that that
function annotates a single contiguous memory buffer (for example the
std::deque's internal chunk). Such containers have the beginning of
allocated memory block, beginning of the container in-use data, end of
the container's in-use data and the end of the allocated memory block.
This also adds a new API function to verify if a double ended contiguous
container is correctly annotated
(__sanitizer_verify_double_ended_contiguous_container).
Since we do not modify the ASan's shadow memory encoding values, the
capability of sanitizing/annotating a prefix of the internal contiguous
memory buffer is limited – up to SHADOW_GRANULARITY-1 bytes may not be
poisoned before the container's in-use data. This can cause false
negatives (situations when ASan will not detect memory corruption in
those areas).
On the other hand, API function interfaces are designed to work even if
this caveat would not exist. Therefore implementations using those
functions will poison every byte correctly, if only ASan (and
compiler-rt) is extended to support it. In other words, if ASan was
modified to support annotating/poisoning of objects lying on addresses
unaligned to SHADOW_GRANULARITY (so e.g. prefixes of those blocks),
which would require changing its shadow memory encoding, this would not
require any changes in the libcxx std::string/deque code which is added
in further commits of this patch series.
If you have any questions, please email:
advenam.tacet@trailofbits.comdisconnect3d@trailofbits.com
Differential Revision: https://reviews.llvm.org/D132090
This amends commit 00be3578e0 to demangle symbol
names in global descriptors. We keep the mangled name for the `__odr_gen_asan_*`
variables and the runtime __cxa_demangle call site change (which fixed possible
leaks for other scenarios: non-fatal diagnostics).
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cpp uses
an undefined weak `__cxa_demangle` which does not pull in an archive definition.
A -static-libstdc++ executable link does not get demangled names.
Unfortunately this means we cannot rely on runtime demangling.
See compiler-rt/test/asan/TestCases/global-demangle.cpp
The runtime calls `MaybeDemangleGlobalName` for error reporting and
`__cxxabiv1::__cxa_demangle` is called if available, so demanging Itanium
mangled names in global metadata is unnecessary and wastes data size.
Add `MaybeDemangleGlobalName` in ODR violation detection to support demangled
names in a suppressions file. `MaybeDemangleGlobalName` may call
`DemangleCXXABI` and leak memory. Use an internal allocation to prevent lsan
leak (in case there is no fatal asan error).
The debug feature `report_globals=2` prints information for all instrumented
global variables. `MaybeDemangleGlobalName` would be slow, so don't do that.
The output looks like `Added Global[0x56448f092d60]: beg=0x56448fa66d60 size=4/32 name=_ZL13test_global_2`
and I think the mangled name is fine.
Other mangled schemes e.g. Windows (see win-string-literal.ll) remain the
current behavior.
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D138095
With all of the writing of the memprof profile consolidated into one
place, there is no need to set up the profile file (which creates the
file and also redirects all printing from the runtime to it) until we
are ready to dump the profile.
This allows errors and other messages to be dumped to stderr instead of
the profile file, which by default is in a binary format. Additionally,
reset the output file to stderr after dumping the profile so that any
requested memprof allocator statistics are printed to stderr.
Differential Revision: https://reviews.llvm.org/D138175
Try to trigger an MTE fault on double/invalid free by touching the first
byte of the allocation with the provided pointer.
Differential Revision: https://reviews.llvm.org/D137352
Add ptrace interceptor support for LoongArch, `ptrace.cpp` has been
tested and passed.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D137228
This test was unsupported in iOS when a more accurate test is that the architecture is x86_64. This "fix" is first in a series of updates intended to get asan arm64 tests fully functional.
Reviewed By: thetruestblue, vitalybuka
Differential Revision: https://reviews.llvm.org/D138001
LLVM runtimes build already loads the LLVM config and sets all
appropriate variables, no need to do it again.
Differential Revision: https://reviews.llvm.org/D137870
The call to the thread_get_state syscall (that fetches the register values for a thread) on arm64 is mistakenly claiming that the buffer to receive the register state is larger that its actual size on the stack -- the struct on the stack is arm_thread_state64_t, but the MACHINE_THREAD_STATE + MACHINE_THREAD_STATE_COUNT refer to the "unified arm state" struct (which is larger).
Fixes https://github.com/llvm/llvm-project/issues/58503.
Differential Revision: https://reviews.llvm.org/D137292
During __orc_rt_macho_jit_dlopen the ORC runtime will make a request to the JIT
to push any new initializers. Since this call may add new JD-state to the
runtime (and is expected to in general) we need to unlock the JDStatesMutex
during this operation (and similarly when running initializers and atexits, as
these may call trigger push-initializers recursively).
No testcase yet: I haven't been able to reproduce the deadlock when running
llvm-jitlink in in-process mode, and we don't support out-of-process mode in
regression tests yet.
Linux/LoongArch doesn't preserve temporary registers across syscalls,
so we have to explicitly mark them as clobbered to avoid trashing local variables.
Reviewed By: xry111, xen0n, tangyouling, SixWeining
Differential Revision: https://reviews.llvm.org/D137396
Fixes the `FastUnwindTest` unit test for LoongArch.
This change is similar to RISCV D90574.
The following test cases pass after applying the patch:
```
$ ./runtimes/runtimes-bins/compiler-rt/lib/sanitizer_common/tests/Sanitizer-loongarch64-Test
...
[ FAILED ] FastUnwindTest.Basic
[ FAILED ] FastUnwindTest.FramePointerLoop
[ FAILED ] FastUnwindTest.MisalignedFramePointer
[ FAILED ] FastUnwindTest.FPBelowPrevFP
[ FAILED ] FastUnwindTest.CloseToZeroFrame
```
Reviewed By: SixWeining, xen0n, MaskRay
Differential Revision: https://reviews.llvm.org/D137314
The bit-30 in this `__flags` means the address error is due to memory load, and the
bit-31 means the address error is due to memory store. (see SC_ADDRERR_RD
and SC_ADDRERR_WR in kernel arch/loongarch/include/uapi/asm/sigcontext.h).
`illegal_write_test.cpp` and `illegal_read_test.cpp` have been tested and passed.
Reviewed By: SixWeining, xen0n, XiaodongLoong
Differential Revision: https://reviews.llvm.org/D137231
Vitaly Buka