10 Commits

Author SHA1 Message Date
Roland McGrath
fd7ec90abd [lsan] On Fuchsia, don't use atexit hook for leak checks
This is a re-land of https://reviews.llvm.org/D86171 with fix.

Fuchsia's system libraries are instrumented and use the lsan
allocator for internal purposes.  So leak checking needs to run
after all atexit hooks and after the system libraries' internal
exit-time hooks.  The <zircon/sanitizer.h> hook API calls the
__sanitizer_process_exit_hook function at exactly the right time.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D88248
2022-03-29 17:13:55 -07:00
Kirill Stoimenov
572d1ecccc [ASan] Missed some SHADOW_XYZ uses on non-Linux platforms.
Reviewed By: kstoimenov

Differential Revision: https://reviews.llvm.org/D115307
2021-12-08 00:39:26 +00:00
Dan Liew
757b93bb7b [ASan] Fix broken Windows build due to 596d534ac3524052df210be8d3c01a33b2260a42.
In that change I forgot to update the call to
`AsanThread::ThreadStart()` in `asan_win.cpp`.
2021-01-23 09:09:06 -08:00
Nikita Popov
f161e84c10 Revert "[lsan] On Fuchsia, don't use atexit hook for leak checks"
This reverts commit 0caad9fe441d5ee562e96d8b30b5574b492a933a.
This reverts commit c96d0cceb684fa176b51d7df5f4f8370e2c983f4.

Causes linker errors which were not fixed by the subsequent commit
either:

/home/nikic/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:503: error: undefined reference to '__asan::InstallAtExitCheckLeaks()'
2020-09-23 21:10:56 +02:00
Roland McGrath
0caad9fe44 [lsan] On Fuchsia, don't use atexit hook for leak checks
Fuchsia's system libraries are instrumented and use the lsan
allocator for internal purposes.  So leak checking needs to run
after all atexit hooks and after the system libraries' internal
exit-time hooks.  The <zircon/sanitizer.h> hook API calls the
__sanitizer_process_exit_hook function at exactly the right time.

Reviewed By: vitalybuka, phosek

Differential Revision: https://reviews.llvm.org/D86171
2020-09-23 11:10:58 -07:00
Marco Vanotti
db00fac2a2 [compiler-rt][asan] decommit shadow memory for unmaps in fuchsia.
This CL allows asan allocator in fuchsia to decommit shadow memory
for memory allocated using mmap.

Big allocations in asan end up being allocated via `mmap` and freed with
`munmap`. However, when that memory is freed, asan returns the
corresponding shadow memory back to the OS via a call to
`ReleaseMemoryPagesToOs`.

In fuchsia, `ReleaseMemoryPagesToOs` is a no-op: to be able to free
memory back to the OS, you have to hold a handle to the vmo you want to
modify, which is tricky at the ReleaseMemoryPagesToOs level as that
function is not exclusively used for shadow memory.

The function `__sanitizer_fill_shadow` fills a given shadow memory range
with a specific value, and if that value is 0 (unpoison) and the memory
range is bigger than a threshold parameter, it will decommit that memory
if it is all zeroes.

This CL modifies the `FlushUnneededASanShadowMemory` function in
`asan_poisoning.cpp` to add a call to `__sanitizer_fill_shadow` with
value and threshold = 0. This way, all the unneeded shadow memory gets
returned back to the OS.

A test for this behavior can be found in fxrev.dev/391974

Differential Revision: https://reviews.llvm.org/D80355

Change-Id: Id6dd85693e78a222f0329d5b2201e0da753e01c0
2020-07-21 11:07:47 -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
Robert Schneider
387e94ca92 [asan] Refactor stack unpoisoning.
Summary: This adds a customization point to support unpoisoning of signal alternate stacks on POSIX.

Reviewers: vitalybuka

Reviewed By: vitalybuka

Subscribers: #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D81577
2020-06-16 01:52:44 -07:00
Vitaly Buka
c0fa632236 Remove NOLINTs from compiler-rt
llvm-svn: 371687
2019-09-11 23:19:48 +00:00
Nico Weber
217222abea compiler-rt: Rename .cc file in lib/asan to .cpp
Like r367463, but for asan.

llvm-svn: 367558
2019-08-01 13:43:28 +00:00