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
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).
Fuchsia's libc provides a new hook (__sanitizer_module_loaded) which calls
hwasan_library_loaded in the startup path which will register globals in
loaded modules.
Differential Revision: https://reviews.llvm.org/D137676
This reverts commit 59052468c3.
It looks like this patch breaks the build when compiler-rt is passed to
LLVM_ENABLE_PROJECTS instead of LLVM_ENABLE_RUNTIMES.
This will help improve the project's layering, so that sub-projects
that don't actually need any llvm code can still use googletest
without having to reference code in the llvm directory.
This will also make it easier to consolidate and simplify the standalone
build configurations.
Reviewed By: stellaraccident, lattner, probinson, phosek
Differential Revision: https://reviews.llvm.org/D131919
The glibc uses the define to avoid namespace polution on headers
that requires variadic argument, where the inclusion of stdarg.h is
required to obtain the va_list definition.
For such cases only __gnuc_va_list is required.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D137268
syscall makes it failed to build on mips64 for mipsel:
```
compiler-rt/lib/builtins/clear_cache.c:97:3: error:
call to undeclared function 'syscall'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
syscall(__NR_cacheflush, start, (end_int - start_int), BCACHE);
```
In this patch, we use `rdhwr` to get synci_step.
If synci_step is zero, it means that the hardware will maintain the coherence. We need to do nothing.
Then for r6+, `synci` is required to keep icache global.
So we can use `synci` to flush icache.
The ISA documents ask a `sync` and a `jr.hb` after `synci`.
For pre-r6, we can use cacheflush libc function, which is same on Linux and FreeBSD.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135565
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
When building libstd on Rust for a riscv32 target, `compiler-rt` fails to build with the following error:
```
running: "riscv-none-elf-gcc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-march=rv32imac" "-mabi=ilp32" "-mcmodel=medany" "-fno-builtin" "-fvisibility=hidden" "-ffreestanding" "-fomit-frame-pointer" "-ffile-prefix-map=E:\\Code\\Xous\\rust-next\\src\\llvm-project\\compiler-rt=." "-DVISIBILITY_HIDDEN" "-o" "E:\\Code\\Xous\\rust-next\\target\\riscv32imac-unknown-xous-elf\\release\\build\\compiler_builtins-b0d7dd25c6999904\\out\\absvdi2.o" "-c" "E:\\Code\\Xous\\rust-next\\src\\llvm-project\\compiler-rt\\lib/builtins\\absvdi2.c"
cargo:warning=In file included from E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\int_lib.h:99,
cargo:warning= from E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\absvdi2.c:13:
cargo:warning=E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\int_types.h:79:1: error: unable to emulate 'TI'
cargo:warning= 79 | typedef int ti_int __attribute__((mode(TI)));
cargo:warning= | ^~~~~~~
cargo:warning=E:\Code\Xous\rust-next\src\llvm-project\compiler-rt\lib/builtins\int_types.h:80:1: error: unable to emulate 'TI'
cargo:warning= 80 | typedef unsigned tu_int __attribute__((mode(TI)));
cargo:warning= | ^~~~~~~
exit code: 1
```
This is because 128-bit support is gated on the `__riscv` compiler macro which is valid for both rv32 and rv64. However, only rv64 has 128-bit support, so this fails when building for rv32.
Add a check for `__SIZEOF_INT128__` to ensure that 128-bit support is only enabled on targets that support it.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D137485
The lowercase __ppc__ is not defined by Linux GCC, therefore it lures
users to write code which is not portable to GCC. Migrate to __powerpc__ in
preparation for undefining __ppc__. __powerpc__ is much more common than
__PPC__.
Fix a brown paper bag error made by me in D129418. I didn't set
ASAN_INTERCEPT_VFORK correctly for loongarch64, but created an all-zero
object for __interception::real_vfork. This caused anything calling
vfork() to die instantly.
Fix this issue by setting ASAN_INTERCEPT_VFORK and remove the bad
all-zero definition. Other ports have an all-zero common definition but
we don't need it at least for now.
And, enable ASAN vfork test for loongarch64 to prevent regression in the
future.
Differential Revision: https://reviews.llvm.org/D137160
This enables odr indicators on all platforms and private aliases on non-Windows.
Note that GCC also uses private aliases: this fixes bogus
`The following global variable is not properly aligned.` errors for interposed global variables
Fix https://github.com/google/sanitizers/issues/398
Fix https://github.com/google/sanitizers/issues/1017
Fix https://github.com/llvm/llvm-project/issues/36893 (we can restore D46665)
Global variables of non-hasExactDefinition() linkages (i.e.
linkonce/linkonce_odr/weak/weak_odr/common/external_weak) are not instrumented.
If an instrumented variable gets interposed to an uninstrumented variable due to
symbol interposition (e.g. in issue 36893, _ZTS1A in foo.so is resolved to _ZTS1A in
the executable), there may be a bogus error.
With private aliases, the register code will not resolve to a definition in
another module, and thus prevent the issue.
Cons: minor size increase. This is mainly due to extra `__odr_asan_gen_*` symbols.
(ELF) In addition, in relocatable files private aliases replace some relocations
referencing global symbols with .L symbols and may introduce some STT_SECTION symbols.
For lld, with -g0, the size increase is 0.07~0.09% for many configurations I
have tested: -O0, -O1, -O2, -O3, -O2 -ffunction-sections -fdata-sections
-Wl,--gc-sections. With -g1 or above, the size increase ratio will be even smaller.
This patch obsoletes D92078.
Don't migrate Windows for now: the static data member of a specialization
`std::num_put<char>::id` is a weak symbol, as well as its ODR indicator.
Unfortunately, link.exe (and lld without -lldmingw) generally doesn't support
duplicate weak definitions (weak symbols in different TUs likely pick different
defined external symbols and conflict).
Differential Revision: https://reviews.llvm.org/D137227
Advenam Tacet