Main goal is to remove thread registry dependency from the interface because HWASAN is using its own code to manage threads.
Reviewed By: vitalybuka, kstoimenov
Differential Revision: https://reviews.llvm.org/D140039
Breaks bots.
Also it's missing changes we discussed on review.
This reverts commit f001e50f955c3cdf2deb79e38a9fd19c9a781882.
This reverts commit 2924189233fdb724453ead4b94595107b1ce9cfa.
Main goal is to remove thread registry dependency from the interface because HWASAN is using its own code to manage threads.
Reviewed By: vitalybuka, kstoimenov
Differential Revision: https://reviews.llvm.org/D140039
When trying to debug some `compiler-rt` unittests, I initially had a hard
time because
- even in a `Debug` build one needs to set `COMPILER_RT_DEBUG` to get
debugging info for some of the code and
- even so the unittests used a hardcoded `-O2` which often makes debugging
impossible.
This patch addresses this by instead using `-O0` if `COMPILER_RT_DEBUG`.
Changes relative to the previous commit:
- Use `string(APPEND)` for `COMPILER_RT_TEST_COMPILER_CFLAGS`.
- Omit `-O3` from `COMPILER_RT_TEST_COMPILER_CFLAGS` in non-debug builds for now.
- Provide `__sanitizer::integral_constant<bool, true>::value` instantiation
for `sanitizer_type_traits_test.cpp` in debug builds.
- Disable subtests of `tsan/tests/unit/tsan_trace_test.cpp` that deadlock
in debug builds.
- `XFAIL` `tsan/Linux/check_memcpy.c` in debug builds.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D91620
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 00be3578e0841dd9abe408e5b4946180de0bf46b 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
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 patch should land before D137136 to make sure that the leak sanitizer allocator works correctly. This patch is NFC without D137136.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D137265
- Add get_bits_for_arch for loongarch64 detection, fix the following error,
```
$ make check-asan
-- sanitizer_common tests on "Linux" will run against "asan"
CMake Error at test/asan/CMakeLists.txt:22 (message):
Unknown target architecture: loongarch64
Call Stack (most recent call first):
test/asan/CMakeLists.txt:49 (get_bits_for_arch)
```
- Do not use __builtin_longjmp, fix the following error,
```
llvm-project/compiler-rt/lib/asan/tests/asan_test.cpp:635:3: error: __builtin_longjmp is not supported for the current target
__builtin_longjmp((void**)buf, 1);
```
Differential Revision: https://reviews.llvm.org/D137012
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 extends a compiler-rt ASan sanitization API function sanitizer_annotate_contiguous_container used to sanitize/annotate containers like std::vector to support different allocators and situations when granules are shared between objects. Those changes are necessary to support annotating objects' self memory (in contrast to annotating memory allocated by an object) like short std::basic_string (with short string optimization). That also allows use of non-standard memory allocators, as alignment requirement is no longer necessary.
This also updates an API function to verify if a double ended contiguous container is correctly annotated (__sanitizer_verify_contiguous_container).
If you have any questions, please email:
advenam.tacet@trailofbits.comdisconnect3d@trailofbits.com
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D132522
Additional calls were introduced for outlining (opposite of inlining)
in https://reviews.llvm.org/D136197 which contain asserts that partial
poisoning of a single byte wouldn't happen consecutively but this is
too strong and actually does occur in Windows. Removing those asserts
as they are unnecessary
Differential Revision: https://reviews.llvm.org/D136645
When -asan-max-inline-poisoning-size=0, all shadow memory access should be
outlined (through asan calls). This was not occuring when partial poisoning
was required on the right side of a variable's redzone. This diff contains
the changes necessary to implement and utilize __asan_set_shadow_01() through
__asan_set_shadow_07(). The change is necessary for the full abstraction of
the asan implementation and will enable experimentation with alternate strategies.
Differential Revision: https://reviews.llvm.org/D136197
When in-tree libcxx is selected as the sanitizer C++ ABI, use
libcxx-abi-* targets rather than libcxxabi and libunwind directly.
Differential Revision: https://reviews.llvm.org/D134855
When trying to debug some `compiler-rt` unittests, I initially had a hard
time because
- even in a `Debug` build one needs to set `COMPILER_RT_DEBUG` to get
debugging info for some of the code and
- even so the unittests used a hardcoded `-O2` which often makes debugging
impossible.
This patch addresses this by instead using `-O0` if `COMPILER_RT_DEBUG`.
Two tests in `sanitizer_type_traits_test.cpp` need to be disabled since
they have undefined references to `__sanitizer::integral_constant<bool,
true>::value`.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D91620
It casued some runtimes builds to fail with cmake error
No target "libcxx-abi-static"
see code review.
> When in-tree libcxx is selected as the sanitizer C++ ABI, use
> libcxx-abi-* targets rather than libcxxabi and libunwind directly.
>
> Differential Revision: https://reviews.llvm.org/D134855
This reverts commit 414f9b7d2f45670019dc8ec284b685a9e238718f.
When in-tree libcxx is selected as the sanitizer C++ ABI, use
libcxx-abi-* targets rather than libcxxabi and libunwind directly.
Differential Revision: https://reviews.llvm.org/D134855
ClearShadowMemoryForContextStack assumes that context contains the stack
bounds. This is not true for a context from getcontext or oucp of
swapcontext.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D130218
Depends on D129371.
It survived all GCC ASan tests.
Changes are trivial and mostly "borrowed" RISC-V logics, except that a different SHADOW_OFFSET is used.
Reviewed By: SixWeining, MaskRay, XiaodongLoong
Differential Revision: https://reviews.llvm.org/D129418
