Reapply "[HWASan] [compiler-rt] support non-4k pages on Android" (#95853)

Updated MapDynamicShadow callsite in asan_win.

[sanitizer] Lift AsanDoesNotSupportStaticLinkage to sanitizer_common.h. NFC (#80948)

The `_DYNAMIC` reference from `AsanDoesNotSupportStaticLinkage` ensures
that `clang++ -fsanitize=address -static

[sanitizer] Lift AsanDoesNotSupportStaticLinkage to sanitizer_common.h. NFC (#80948)

The `_DYNAMIC` reference from `AsanDoesNotSupportStaticLinkage` ensures
that `clang++ -fsanitize=address -static` gets a linker error.
`MemprofDoesNotSupportStaticLinkage` is similar for `-fmemory-profile`.
Move the functions to sanitizer_common.h to be used by more sanitizers
on ELF platforms.

Fuchsia does not use interposition and opts out the check (its
`AsanDoesNotSupportStaticLinkage` is a no-op).

show more ...

[ASAN][sanitizers][win] Allow windows-asan to be built with /MDd and intercept functions from the debug runtimes. (#77840)

It turns out this works _mostly_ fine, even when mixing debug versions
of

[ASAN][sanitizers][win] Allow windows-asan to be built with /MDd and intercept functions from the debug runtimes. (#77840)

It turns out this works _mostly_ fine, even when mixing debug versions
of asan with programs built with the release runtime. Using /MT (or
/MTd) with a dynamically linked asan has never really worked that well,
and I am planning on opening a PR that will completely remove the
static-asan configuration for windows and make programs linked with the
static CRT/runtime work with the DLL version of asan. This is better
than the current situation because the static linked version of asan
doesn't work well on windows if there are multiple DLLs in the process
using it.

The check for building asan with only /MD or /MT has been removed. It
was in AsanDoesNotSupportStaticLinkage, but was checking for debug CRTs,
not static linkage. The kind of static linkage this function is supposed
to check for (on linux for example) doesn't really exist on windows.

Note: There is one outstanding issue with this approach, if you mix a
/MDd DLLs and /MD dlls in the same process then the "real" function
called by asan interceptors will be the same for calls from both
contexts, potentially screwing up things like errno. This only happens
if you mix /MD and /MDd in the same process, because otherwise asan
won't find functions from both runtimes to intercept. We are working on
a fix for this, and it mainly hits with the CRT functions exported from
both ucrtbase and ntdll.


This change is being upstreamed from Microsoft's fork.

show more ...

[asan] Install `pthread_atfork` (#75290)

This prevents deadlocks in forked process
if parent had more then one running threads.

[NFC][asan] Replace start_routine_ and arg_ with opaque start_data_ field

start_data_ is platform specific.

Reviewed By: kstoimenov

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

[NFC][asan] Split AsanThread::ThreadStart

Reviewed By: kstoimenov

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

Fix typo in b9863430

[NFC] Remove Win specific Destroy from ThreadStart

[compiler-rt][interception][asan][win] Improve error reporting

Add a callback from interception to allow asan on Windows to produce
better error messages. If an unrecoverable error occured when
inte

[compiler-rt][interception][asan][win] Improve error reporting

Add a callback from interception to allow asan on Windows to produce
better error messages. If an unrecoverable error occured when
intercepting functions, print a message before terminating.

Additionally, when encountering unknown instructions, a more helpful
message containing the address and the bytes of the unknown instruction
is now printed to help identify the issue and make it easier to propose
a fix.

Depends on D149549

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

show more ...

[sanitizer][asan][win] Only unmap unneeded shadow memory on x86_64

D21942 / 1128db8fe1c13800ebc77206efc50d0a219b8750 added support for
committing shadow memory on demand on Win 64-bit. The reason it

[sanitizer][asan][win] Only unmap unneeded shadow memory on x86_64

D21942 / 1128db8fe1c13800ebc77206efc50d0a219b8750 added support for
committing shadow memory on demand on Win 64-bit. The reason it is not
enabled on 32-bit wasn't clear but the page table overhead on Windows 7
may be a contributing factor.

In `AsanMapUnmapCallback::OnUnmap`, `FlushUnneededASanShadowMemory` is
called to release shadow memory. It calls `ReleaseMemoryPagesToOS`,
which had been a no-op on Windows, until D95892 /
81b1d3da094c54ffd75e05c8d4683792edf17f4c in which it was changed to
unmap full pages that the memory region covers. This was done on both
32-bit and 64-bit.

AddressSanitizerInterface.GetHeapSizeTest appears to fail on i686
targets as a side effect of this. This test allocates and frees a huge
chunk of memory which causes shadow memory to be unmapped immediately.
When the test allocates the chunk of memory a second time, asan tries to
reuse the same shadow memory region, but because the shadow memory has
now been unmapped, it causes an access violation and crashes the test.

x86_64 is not affected, because the code that handles commiting shadow
memory on demand also handles this situation, allowing the test to work
without crashing.

Therefore, this patch changes `FlushUnneededASanShadowMemory` on Windows
to only release/unmap the shadow memory on x86_64 to stop this from
happening on i686.

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

show more ...

[NFC][asan] Guard implemetation with ASAN_INTERCEPT_SWAPCONTEXT

[asan] Reset stack bounds of context

ClearShadowMemoryForContextStack assumes that context contains the stack
bounds. This is not true for a context from getcontext or oucp of
swapcontext.

Reviewed

[asan] Reset stack bounds of context

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

show more ...

[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 in

[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

show more ...

[ASan] Missed some SHADOW_XYZ uses on non-Linux platforms.

Reviewed By: kstoimenov

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

[ASan] Fix broken Windows build due to 596d534ac3524052df210be8d3c01a33b2260a42.

In that change I forgot to update the call to
`AsanThread::ThreadStart()` in `asan_win.cpp`.

Revert "[lsan] On Fuchsia, don't use atexit hook for leak checks"

This reverts commit 0caad9fe441d5ee562e96d8b30b5574b492a933a.
This reverts commit c96d0cceb684fa176b51d7df5f4f8370e2c983f4.

Causes

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()'

show more ...

[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

[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

show more ...

[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

[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

show more ...

[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.

[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

show more ...

[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:

[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

show more ...

Remove NOLINTs from compiler-rt

llvm-svn: 371687

compiler-rt: Rename .cc file in lib/asan to .cpp

Like r367463, but for asan.

llvm-svn: 367558