Commit Graph

239 Commits

Author SHA1 Message Date
Leonard Chan d4e4799998 [NFC][compiler-rt][hwasan] Refactor hwasan functions
This moves the implementations for HandleTagMismatch, __hwasan_tag_mismatch4,
and HwasanAtExit from hwasan_linux.cpp to hwasan.cpp and declares them in hwasan.h.
This way, calls to those functions can be shared with the fuchsia implementation
without duplicating code.

Differential Revision: https://reviews.llvm.org/D103562
2021-06-03 14:26:35 -07:00
Matt Morehouse d97bab6511 [HWASan] Don't build alias mode on non-x86.
Alias mode is not expected work on non-x86, so don't build it there.
Should fix the aarch64 bot.
2021-05-17 10:32:16 -07:00
Matt Morehouse 5f58322368 [HWASan] Build separate LAM runtime on x86_64.
Since we have both aliasing mode and Intel LAM on x86_64, we need to
choose the mode at either run time or compile time.  This patch
implements the plumbing to build both and choose between them at
compile time.

Reviewed By: vitalybuka, eugenis

Differential Revision: https://reviews.llvm.org/D102286
2021-05-17 09:19:06 -07:00
Dmitry Vyukov 2721e27c3a sanitizer_common: deduplicate CheckFailed
We have some significant amount of duplication around
CheckFailed functionality. Each sanitizer copy-pasted
a chunk of code. Some got random improvements like
dealing with recursive failures better. These improvements
could benefit all sanitizers, but they don't.

Deduplicate CheckFailed logic across sanitizers and let each
sanitizer only print the current stack trace.
I've tried to dedup stack printing as well,
but this got me into cmake hell. So let's keep this part
duplicated in each sanitizer for now.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D102221
2021-05-12 08:50:53 +02:00
Evgenii Stepanov 18959a6a09 [hwasan] Fix missing synchronization in AllocThread.
The problem was introduced in D100348.

It's really hard to trigger the bug in a stress test - the race is just too
narrow - but the new checks in Thread::Init should at least provide usable
diagnostic if the problem ever returns.

Differential Revision: https://reviews.llvm.org/D101881
2021-05-05 11:57:18 -07:00
Nico Weber d7ec48d71b [clang] accept -fsanitize-ignorelist= in addition to -fsanitize-blacklist=
Use that for internal names (including the default ignorelists of the
sanitizers).

Differential Revision: https://reviews.llvm.org/D101832
2021-05-04 10:24:00 -04:00
Fangrui Song 2fec8860d8 [sanitizer] Set IndentPPDirectives: AfterHash in .clang-format
Code patterns like this are common, `#` at the line beginning
(https://google.github.io/styleguide/cppguide.html#Preprocessor_Directives),
one space indentation for if/elif/else directives.
```
#if SANITIZER_LINUX
# if defined(__aarch64__)
# endif
#endif
```

However, currently clang-format wants to reformat the code to
```
#if SANITIZER_LINUX
#if defined(__aarch64__)
#endif
#endif
```

This significantly harms readability in my review.  Use `IndentPPDirectives:
AfterHash` to defeat the diagnostic. clang-format will now suggest:

```
#if SANITIZER_LINUX
#  if defined(__aarch64__)
#  endif
#endif
```

Unfortunately there is no clang-format option using indent with 1 for
just preprocessor directives. However, this is still one step forward
from the current behavior.

Reviewed By: #sanitizers, vitalybuka

Differential Revision: https://reviews.llvm.org/D100238
2021-05-03 13:49:41 -07:00
Evgenii Stepanov 51aa61e74b [hwasan] Fix lock contention on thread creation.
Do not hold the free/live thread list lock longer than necessary.
This change speeds up the following benchmark 10x.

constexpr int kTopThreads = 50;
constexpr int kChildThreads = 20;
constexpr int kChildIterations = 8;

void Thread() {
  for (int i = 0; i < kChildIterations; ++i) {
    std::vector<std::thread> threads;
    for (int i = 0; i < kChildThreads; ++i)
      threads.emplace_back([](){});
    for (auto& t : threads)
      t.join();
  }
}

int main() {
  std::vector<std::thread> threads;
  for (int i = 0; i < kTopThreads; ++i)
    threads.emplace_back(Thread);
  for (auto& t : threads)
    t.join();
}

Differential Revision: https://reviews.llvm.org/D100348
2021-04-14 17:13:15 -07:00
Pirama Arumuga Nainar 5d214238a1 [compiler-rt][aarch64] Add PAC-RET/BTI property to hwasan_interceptors_vfork.S
D100143 added similar annotations but missed this file.

Differential Revision: https://reviews.llvm.org/D100354
2021-04-12 17:17:33 -07:00
Daniel Kiss a46effbd2a [compiler-rt][aarch64] Add PAC-RET/BTI support to HWASAN.
Support for -mbranch-protection.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D100143
2021-04-12 17:02:45 +02:00
Leonard Chan a7b51d8a4f [compiler-rt][hwasan] Add C++17 new/delete operators with alignment
Differential Revision: https://reviews.llvm.org/D99368
2021-04-08 15:44:39 -07:00
Nico Weber 0e92cbd6a6 Revert "[sanitizer] Simplify GetTls with dl_iterate_phdr on Linux"
This reverts commit ec575e3b0a.
Still doesn't work, see https://crbug.com/1196037
2021-04-05 19:00:18 -04:00
Fangrui Song ec575e3b0a [sanitizer] Simplify GetTls with dl_iterate_phdr on Linux
This was reverted by f176803ef1 due to
Ubuntu 16.04 x86-64 glibc 2.23 problems.
This commit additionally calls `__tls_get_addr({modid,0})` to work around the
dlpi_tls_data==NULL issues for glibc<2.25
(https://sourceware.org/bugzilla/show_bug.cgi?id=19826)

GetTls is the range of

* thread control block and optional TLS_PRE_TCB_SIZE
* static TLS blocks plus static TLS surplus

On glibc, lsan requires the range to include
`pthread::{specific_1stblock,specific}` so that allocations only referenced by
`pthread_setspecific` can be scanned.

This patch uses `dl_iterate_phdr` to collect TLS blocks. Find the one
with `dlpi_tls_modid==1` as one of the initially loaded module, then find
consecutive ranges. The boundaries give us addr and size.

This allows us to drop the glibc internal `_dl_get_tls_static_info` and
`InitTlsSize` entirely. Use the simplified method with non-Android Linux for
now, but in theory this can be used with *BSD and potentially other ELF OSes.

This simplification enables D99566 for TLS Variant I architectures.

See https://reviews.llvm.org/D93972#2480556 for analysis on GetTls usage
across various sanitizers.

Differential Revision: https://reviews.llvm.org/D98926
2021-04-04 15:35:53 -07:00
Nico Weber f176803ef1 Revert "[sanitizer] Simplify GetTls with dl_iterate_phdr"
This reverts commit 9be8f8b34d.
This breaks tsan on Ubuntu 16.04:

    $ cat tiny_race.c
    #include <pthread.h>
    int Global;
    void *Thread1(void *x) {
      Global = 42;
      return x;
    }
    int main() {
      pthread_t t;
      pthread_create(&t, NULL, Thread1, NULL);
      Global = 43;
      pthread_join(t, NULL);
      return Global;
    }
    $ out/gn/bin/clang -fsanitize=thread -g -O1 tiny_race.c --sysroot ~/src/chrome/src/build/linux/debian_sid_amd64-sysroot/
    $ docker run -v $PWD:/foo ubuntu:xenial /foo/a.out
    FATAL: ThreadSanitizer CHECK failed: ../../compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp:447 "((thr_beg)) >= ((tls_addr))" (0x7fddd76beb80, 0xfffffffffffff980)
        #0 <null> <null> (a.out+0x4960b6)
        #1 <null> <null> (a.out+0x4b677f)
        #2 <null> <null> (a.out+0x49cf94)
        #3 <null> <null> (a.out+0x499bd2)
        #4 <null> <null> (a.out+0x42aaf1)
        #5 <null> <null> (libpthread.so.0+0x76b9)
        #6 <null> <null> (libc.so.6+0x1074dc)

(Get the sysroot from here: https://commondatastorage.googleapis.com/chrome-linux-sysroot/toolchain/500976182686961e34974ea7bdc0a21fca32be06/debian_sid_amd64_sysroot.tar.xz)

Also reverts follow-on commits:
This reverts commit 58c62fd976.
This reverts commit 31e541e375.
2021-04-02 18:19:17 -04:00
Fangrui Song 9be8f8b34d [sanitizer] Simplify GetTls with dl_iterate_phdr
GetTls is the range of

* thread control block and optional TLS_PRE_TCB_SIZE
* static TLS blocks plus static TLS surplus

On glibc, lsan requires the range to include
`pthread::{specific_1stblock,specific}` so that allocations only referenced by
`pthread_setspecific` can be scanned.

This patch uses `dl_iterate_phdr` to collect TLS ranges. Find the one
with `dlpi_tls_modid==1` as one of the initially loaded module, then find
consecutive ranges. The boundaries give us addr and size.

This allows us to drop the glibc internal `_dl_get_tls_static_info` and
`InitTlsSize` entirely. Use the simplified method with non-Android Linux for
now, but in theory this can be used with *BSD and potentially other ELF OSes.

In the future, we can move `ThreadDescriptorSize` code to lsan (and consider
intercepting `pthread_setspecific`) to avoid hacks in generic code.

See https://reviews.llvm.org/D93972#2480556 for analysis on GetTls usage
across various sanitizers.

Differential Revision: https://reviews.llvm.org/D98926
2021-03-25 21:55:27 -07:00
Matt Morehouse 96a4167b4c [HWASan] Use page aliasing on x86_64.
Userspace page aliasing allows us to use middle pointer bits for tags
without untagging them before syscalls or accesses.  This should enable
easier experimentation with HWASan on x86_64 platforms.

Currently stack, global, and secondary heap tagging are unsupported.
Only primary heap allocations get tagged.

Note that aliasing mode will not work properly in the presence of
fork(), since heap memory will be shared between the parent and child
processes.  This mode is non-ideal; we expect Intel LAM to enable full
HWASan support on x86_64 in the future.

Reviewed By: vitalybuka, eugenis

Differential Revision: https://reviews.llvm.org/D98875
2021-03-25 07:04:14 -07:00
Matt Morehouse c8ef98e5de Revert "[HWASan] Use page aliasing on x86_64."
This reverts commit 63f73c3eb9 due to
breakage on aarch64 without TBI.
2021-03-24 16:18:29 -07:00
Matt Morehouse 63f73c3eb9 [HWASan] Use page aliasing on x86_64.
Userspace page aliasing allows us to use middle pointer bits for tags
without untagging them before syscalls or accesses.  This should enable
easier experimentation with HWASan on x86_64 platforms.

Currently stack, global, and secondary heap tagging are unsupported.
Only primary heap allocations get tagged.

Note that aliasing mode will not work properly in the presence of
fork(), since heap memory will be shared between the parent and child
processes.  This mode is non-ideal; we expect Intel LAM to enable full
HWASan support on x86_64 in the future.

Reviewed By: vitalybuka, eugenis

Differential Revision: https://reviews.llvm.org/D98875
2021-03-24 11:43:41 -07:00
Matt Morehouse 3e4faf08de [HWASan] Refactor in preparation for x86 aliasing mode. NFC
Reviewed By: vitalybuka, eugenis

Differential Revision: https://reviews.llvm.org/D98373
2021-03-23 13:25:10 -07:00
Matt Morehouse fe5f66d925 [HWASan][NFC] Introduce constants for tag bits and masks.
x86_64 aliasing mode will use fewer than 8 bits for tags, so refactor
existing code to remove hard-coded 0xff and 8 values.

Reviewed By: vitalybuka, eugenis

Differential Revision: https://reviews.llvm.org/D98072
2021-03-22 12:32:29 -07:00
Vitaly Buka e0dadf3de2 [sanitizer] Remove max_len parameter from InternalScopedString
InternalScopedString uses InternalMmapVector internally
so it can be resized dynamically as needed.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D98751
2021-03-17 16:57:09 -07:00
Vitaly Buka c88c46080a [NFC] Remove tab from the source 2021-02-26 19:40:24 -08:00
Matthew Malcomson c1653b8cc7 Hwasan InitPrctl check for error using internal_iserror
When adding this function in https://reviews.llvm.org/D68794 I did not
notice that internal_prctl has the API of the syscall to prctl rather
than the API of the glibc (posix) wrapper.

This means that the error return value is not necessarily -1 and that
errno is not set by the call.

For InitPrctl this means that the checks do not catch running on a
kernel *without* the required ABI (not caught since I only tested this
function correctly enables the ABI when it exists).
This commit updates the two calls which check for an error condition to
use internal_iserror. That function sets a provided integer to an
equivalent errno value and returns a boolean to indicate success or not.

Tested by running on a kernel that has this ABI and on one that does
not. Verified that running on the kernel without this ABI the current
code prints the provided error message and does not attempt to run the
program. Verified that running on the kernel with this ABI the current
code does not print an error message and turns on the ABI.
This done on an x86 kernel (where the ABI does not exist), an AArch64
kernel without this ABI, and an AArch64 kernel with this ABI.

In order to keep running the testsuite on kernels that do not provide
this new ABI we add another option to the HWASAN_OPTIONS environment
variable, this option determines whether the library kills the process
if it fails to enable the relaxed syscall ABI or not.
This new flag is `fail_without_syscall_abi`.
The check-hwasan testsuite results do not change with this patch on
either x86, AArch64 without a kernel supporting this ABI, and AArch64
with a kernel supporting this ABI.

Differential Revision: https://reviews.llvm.org/D96964
2021-02-19 16:30:56 +00:00
Nico Weber 704831fe1f Revert "Hwasan InitPrctl check for error using internal_iserror"
This reverts commit 1854594b80.
See https://reviews.llvm.org/D94425#2495621
2021-01-13 08:30:11 -05:00
Matthew Malcomson 1854594b80 Hwasan InitPrctl check for error using internal_iserror
When adding this function in https://reviews.llvm.org/D68794 I did not
notice that internal_prctl has the API of the syscall to prctl rather
than the API of the glibc (posix) wrapper.

This means that the error return value is not necessarily -1 and that
errno is not set by the call.

For InitPrctl this means that the checks do not catch running on a
kernel *without* the required ABI (not caught since I only tested this
function correctly enables the ABI when it exists).
This commit updates the two calls which check for an error condition to
use `internal_iserror`.  That function sets a provided integer to an
equivalent errno value and returns a boolean to indicate success or not.

Tested by running on a kernel that has this ABI and on one that does
not.  Verified that running on the kernel without this ABI the current
code prints the provided error message and does not attempt to run the
program.  Verified that running on the kernel with this ABI the current
code does not print an error message and turns on the ABI.
All tests done on an AArch64 Linux machine.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D94425
2021-01-13 11:35:09 +00:00
Evgenii Stepanov 08d90f72ce [hwasan] Implement error report callback.
Similar to __asan_set_error_report_callback, pass the entire report to a
user provided callback function.

Differential Revision: https://reviews.llvm.org/D91825
2020-11-20 16:48:19 -08:00
Evgenii Stepanov 523cc097fd [hwasan] Fix Thread reuse (try 2).
HwasanThreadList::DontNeedThread clobbers Thread::next_,
Breaking the freelist. As a result, only the top of the freelist ever
gets reused, and the rest of it is lost.

Since the Thread object with its associated ring buffer is only 8Kb, this is
typically only noticable in long running processes, such as fuzzers.

Fix the problem by switching from an intrusive linked list to a vector.

Differential Revision: https://reviews.llvm.org/D91392
2020-11-18 16:04:08 -08:00
Matthew Malcomson 83ac18205e Hwasan reporting check for dladdr failing
In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
current address.  `dladdr` returns 0 if it failed.
During testing on Linux this returned 0 to indicate failure, and
populated the `info` structure with a NULL pointer which was
dereferenced later.

This patch checks for `dladdr` returning 0, and in that case returns 0
from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
the address.

This occurs when `GetModuleNameAndOffsetForPC` succeeds for some address
not in a dynamically loaded library.  One example is when the found
"module" is '[stack]' having come from parsing /proc/self/maps.

Differential Revision: https://reviews.llvm.org/D91344
2020-11-16 12:25:27 +00:00
Nico Weber 6ab31eeb62 Revert "[hwasan] Fix Thread reuse."
This reverts commit e1eeb026e6.
Test fails: https://reviews.llvm.org/D91208#2388613
2020-11-11 09:56:21 -05:00
Evgenii Stepanov e1eeb026e6 [hwasan] Fix Thread reuse.
HwasanThreadList::DontNeedThread clobbers Thread::next_, breaking the
freelist. As a result, only the top of the freelist ever gets reused,
and the rest of it is lost.

Since the Thread object its associated ring buffer is only 8Kb, this is
typically only noticable in long running processes, such as fuzzers.

Fix the problem by switching from an intrusive linked list to a vector.

Differential Revision: https://reviews.llvm.org/D91208
2020-11-10 17:24:24 -08:00
Peter Collingbourne 0ae2ea8f83 hwasan: Bring back operator {new,delete} interceptors on Android.
It turns out that we can't remove the operator new and delete
interceptors on Android without breaking ABI, so bring them back
as forwards to the malloc and free functions.

Differential Revision: https://reviews.llvm.org/D91219
2020-11-10 16:05:24 -08:00
Petr Hosek 6db314e86b [CMake] Remove cxx-headers from runtime deps
Part of D88922
2020-10-30 20:03:38 -07:00
Peter Collingbourne 864b3a336b Reland "hwasan: Disable operator {new,delete} interceptors when interceptors are disabled."
There was a discrepancy in the gn build which is now fixed.

Differential Revision: https://reviews.llvm.org/D89827
2020-10-28 15:42:23 -07:00
Nico Weber 6f9d84bb26 Revert "hwasan: Disable operator {new,delete} interceptors when interceptors are disabled."
This reverts commit fa66bcf4bc.
Seems to break tests, see https://reviews.llvm.org/D89827#2351930
2020-10-24 15:04:22 -04:00
Peter Collingbourne fa66bcf4bc hwasan: Disable operator {new,delete} interceptors when interceptors are disabled.
Differential Revision: https://reviews.llvm.org/D89827
2020-10-23 21:03:47 -07:00
Evgenii Stepanov b3ccfa1e0c [hwasan] Increase max allocation size to 1Tb.
2Gb is unreasonably low on devices with 12Gb RAM and more.

Differential Revision: https://reviews.llvm.org/D89750
2020-10-20 14:01:48 -07:00
Petr Hosek 220de1f32a Revert "[CMake] Avoid accidental C++ standard library dependency in sanitizers"
This reverts commit 287c318690 which broke
sanitizer tests that use C++ standard library.
2020-10-14 18:44:09 -07:00
Petr Hosek 287c318690 [CMake] Avoid accidental C++ standard library dependency in sanitizers
While sanitizers don't use C++ standard library, we could still end
up accidentally including or linking it just by the virtue of using
the C++ compiler. Pass -nostdinc++ and -nostdlib++ to avoid these
accidental dependencies.

Differential Revision: https://reviews.llvm.org/D88922
2020-10-14 18:26:56 -07:00
Teresa Johnson 4d5b1de40e [sanitizer] Skip stack symbolization when not required for print format
Adds a check to avoid symbolization when printing stack traces if the
stack_trace_format flag does not need it. While there is a symbolize
flag that can be turned off to skip some of the symbolization,
SymbolizePC() still unconditionally looks up the module name and offset.
Avoid invoking SymbolizePC() at all if not needed.

This is an efficiency improvement when dumping all stack traces as part
of the memory profiler in D87120, for large stripped apps where we want
to symbolize as a post pass.

Differential Revision: https://reviews.llvm.org/D88361
2020-10-07 15:38:52 -07:00
Alexey Baturo aa1b1d35cb [RISCV][ASAN] implementation for vfork interceptor for riscv64
[5/11] patch series to port ASAN for riscv64

Depends On D87573

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D87574
2020-09-22 22:23:29 -07:00
Kamil Rytarowski e7de267910 [compiler-rt] [hwasan] Replace INLINE with inline
Fixes the build after landing D87562.
2020-09-17 16:46:32 +02:00
Fangrui Song 2d7fd38cf7 [sanitizers] Remove unneeded MaybeCall*DefaultOptions() and nullptr checks
D28596 added SANITIZER_INTERFACE_WEAK_DEF which can guarantee `*_default_options` are always defined.
The weak attributes on the `__{asan,lsan,msan,ubsan}_default_options` declarations can thus be removed.

`MaybeCall*DefaultOptions` no longer need nullptr checks, so their call sites can just be replaced by `__*_default_options`.

Reviewed By: #sanitizers, vitalybuka

Differential Revision: https://reviews.llvm.org/D87175
2020-09-08 10:12:05 -07:00
Teresa Johnson 5d2be1a188 [compiler-rt][asan][hwasan] Refactor shadow setup into sanitizer_common (NFCI)
Summary:
This refactors some common support related to shadow memory setup from
asan and hwasan into sanitizer_common. This should not only reduce code
duplication but also make these facilities available for new compiler-rt
uses (e.g. heap profiling).

In most cases the separate copies of the code were either identical, or
at least functionally identical. A few notes:

In ProtectGap, the asan version checked the address against an upper
bound (kZeroBaseMaxShadowStart, which is (2^18). I have created a copy
of kZeroBaseMaxShadowStart in hwasan_mapping.h, with the same value, as
it isn't clear why that code should not do the same check. If it
shouldn't, I can remove this and guard this check so that it only
happens for asan.

In asan's InitializeShadowMemory, in the dynamic shadow case it was
setting __asan_shadow_memory_dynamic_address to 0 (which then sets both
macro SHADOW_OFFSET as well as macro kLowShadowBeg to 0) before calling
FindDynamicShadowStart(). AFAICT this is only needed because
FindDynamicShadowStart utilizes kHighShadowEnd to
get the shadow size, and kHighShadowEnd is a macro invoking
MEM_TO_SHADOW(kHighMemEnd) which in turn invokes:
(((kHighMemEnd) >> SHADOW_SCALE) + (SHADOW_OFFSET))
I.e. it computes the shadow space needed by kHighMemEnd (the shift), and
adds the offset. Since we only want the shadow space here, the earlier
setting of SHADOW_OFFSET to 0 via __asan_shadow_memory_dynamic_address
accomplishes this. In the hwasan version, it simply gets the shadow
space via "MemToShadowSize(kHighMemEnd)", where MemToShadowSize just
does the shift. I've simplified the asan handling to do the same
thing, and therefore was able to remove the setting of the SHADOW_OFFSET
via __asan_shadow_memory_dynamic_address to 0.

Reviewers: vitalybuka, kcc, eugenis

Subscribers: dberris, #sanitizers, llvm-commits, davidxl

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D83247
2020-07-16 11:47:05 -07:00
Arthur Eubanks bf124017a2 [NFC] Rename variable to workaround old gcc bug
Summary:
gcc 5.1 is still supported according to
https://releases.llvm.org/10.0.0/docs/GettingStarted.html

We're hitting the following bug due to a variable created in the loop header being the same as a variable used in the loop header:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430

Reviewers: hctim, pcc

Subscribers: #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D81594
2020-06-10 12:14:53 -07:00
Mitch Phillips e26b25f8b1 [HWASan] Add sizeof(global) in report even if symbols missing.
Summary: Refactor the current global header iteration to be callback-based, and add a feature that reports the size of the global variable during reporting. This allows binaries without symbols to still report the size of the global variable, which is always available in the HWASan globals PT_NOTE metadata.

Reviewers: eugenis, pcc

Reviewed By: pcc

Subscribers: mgorny, llvm-commits, #sanitizers

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D80599
2020-06-09 13:02:13 -07:00
Evgenii Stepanov d1a6e4d2db [hwasan] Disable malloc-fill by default.
Summary: Non-zero malloc fill is causing way too many hard to debug issues.

Reviewers: kcc, pcc, hctim

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D81284
2020-06-05 11:27:16 -07:00
Peter Collingbourne d2a26ad0dc hwasan: Collect ring buffer statistics and include in dev note.
These statistics are intended to help us tune the scudo MTE
implementation.

Differential Revision: https://reviews.llvm.org/D79913
2020-05-14 09:47:42 -07:00
Evgenii Stepanov 9fcd2b68e7 [hwasan] Untag destination address in hwasan_posix_memalign.
Required on X86 because no TBI.
2020-05-08 16:35:48 -07:00
Evgenii Stepanov eaea9ed835 [hwasan] Reset current thread pointer on thread exit.
Summary:
This is necessary to handle calls to free() after __hwasan_thread_exit,
which is possible in glibc.

Also, add a null check to GetCurrentThread, otherwise the logic in
GetThreadByBufferAddress turns it into a non-null value. This means that
all of the checks for GetCurrentThread() != nullptr do not have any
effect at all right now!

Reviewers: pcc, hctim

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D79608
2020-05-08 10:31:25 -07:00
Evgenii Stepanov 6da6153759 hwasan_symbolize: allow 0x in the address field
Summary:
Fix parsing of mangled stack trace lines where the address has been
replaced with "0x", literally.

Reviewers: vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D73823
2020-02-03 18:23:48 -08:00