Any hwasan tag checking done through runtime calls like __hwasan_mem* or
__hwasan_load/store* currently raise a sigtrap on a tag mismatch. Hwasan
dumps as much information it knows on the tag mismatch by placing
important values in specific registers before the brk and encoding the
access information in the optional argument supplied to the brk. If the
platform hwasan runs on uses signal handlers, then users can see the
typical pretty hwasan error report, but Fuchsia doesn't use signal
handlers, so it's left up to the platform exception handler to print all
this encoded information.
This patch attempts to enter the regular error reporting path via
HandleTagMismatch if a new macro CAN_GET_REGISTERS is set. For now this
is only defined for Fuchsia + aarch64, but can be expanded for other
platforms.
Differential Revision: https://reviews.llvm.org/D139377
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
The main thing that needed changing was excluding functionality that
isn't supported on armv4t. So excluding Arm specific builtin assembly files.
In the process some files were renamed and the source was annotated where
appropriate, so it's a bit easier to follow what group of files are meant for
what purpose.
Reviewed By: peter.smith, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D138725
This is needed for LSAN integration work. LSAN uses context to store thread_id << 32 + stack_id. In order to fit both we would need thread_id to be 32 bit.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D139060
The recent change (https://reviews.llvm.org/D137136) to unconditionally
choose the 64 bit allocator on aarch64 breaks Apple iOS family of devices
which purposely use a smaller address space than is used with macOS.
rdar://102527313
Reviewed By: thetruestblue, yln
Differential Revision: https://reviews.llvm.org/D139030
epoll_pwait2 is new and may not be present in libc and/or kernel.
Since we effectively add it to libc (as will be probed by the program
using dlsym or a weak function pointer) we need to handle the case
when it's not present in the actual libc.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D138929
We already know that there are no free blocks above Region->AllocatedUser.
This results in a smaller RegionPageMap and faster releaseFreeMemoryToOS.
Patch By: fabio-d
Differential Revision: https://reviews.llvm.org/D138794
msan's app memory mappings for aarch64 are constrained by
the MEM_TO_SHADOW constant to 64GB or less, and some app
memory mappings (in kMemoryLayout) are even smaller in
practice. This will lead to a crash with the error message
"MemorySanitizer can not mmap the shadow memory" if the
executable's memory mappings (e.g., libraries) extend
beyond msan's app memory mappings.
This patch makes the app/shadow/origin memory mappings
considerably larger, along with corresponding changes to
the MEM_TO_SHADOW and SHADOW_TO_ORIGIN constants.
Note that this deprecates compatibility with 39- and 42-bit
VMAs.
Differential Revision: https://reviews.llvm.org/D137666
This reverts commit ea1826ee57.
This change is breaking the ability of tests to override the profile
output file. Need to add a mechanism to do that before resubmitting.
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
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
Add support for getting the maximum virtual address, LoongArch has multiple
address space layouts, the default maximum virtual address of the current
user space is 47 bits. (from TASK_SIZE in the kernel for loongarch64).
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D137219
This is a counterpart to llvm::orc::SymbolStringPool. It holds uniqued,
ref-counted strings; and can be used to avoid redundant storage of strings,
and speed up comparison of strings held in the pool (these become pointer
comparisons).
Newly added sections can be processed by calling processNewSections. Calling
reset moves all sections back to the "new" state for reprocessing (expected to
be used by dlclose).
