This mode allows an android_mallopt(M_INITIALIZE_GWP_ASAN, ...) to turn
on the recoverable, sampled mode. This is the intended mode for
non-system apps that don't specify the gwpAsanMode in Android U.
Bug: 247012630
Test: Patch the zygote to use this option, launch an app with
gwpAsanMode unspecified, trigger a use-after-free, assert the app uses
the recoverable mode.
Change-Id: I701e10f44b2e2694789cc5ec6f0af4bc0c55b9e4
GWP-ASan's recoverable mode was landed upstream in
https://reviews.llvm.org/D140173.
This mode allows for a use-after-free or a buffer-overflow bug to be
detected by GWP-ASan, a crash report dumped, but then GWP-ASan (through
the preCrashReport() and postCrashReportRecoverableOnly() hooks) will
patch up the memory so that the process can continue, in spite of the
memory safety bug.
This is desirable, as it allows us to consider migrating non-system apps
from opt-in GWP-ASan to opt-out GWP-ASan. The major concern was "if we
make it opt-out, then bad apps will start crashing". If we don't crash,
problem solved :). Obviously, we'll need to do this with an amount of
process sampling to mitigate against the 70KiB memory overhead.
The biggest problem is that the debuggerd signal handler isn't the first
signal handler for apps, it's the sigchain handler inside of libart.
Clearly, the sigchain handler needs to ask us whether the crash is
GWP-ASan's fault, and if so, please patch up the allocator. Because of
linker namespace restrictions, libart can't directly ask the linker
(which is where debuggerd lies), so we provide a proxy function in libc.
Test: Build the platform, run sanitizer-status and various test apps
with recoverable gwp-asan. Assert that it doesn't crash, and we get a
debuggerd report.
Bug: 247012630
Change-Id: I86d5e27a9ca5531c8942e62647fd377c3cd36dfd
Adds persistent sysprops for test infra usage, and adds the tests for
the sysprops.
The test does some fancy flocking in order to restore any existing
GWP-ASan sysprop usage in the test cleanup.
Bug: 236738714
Test: atest bionic-unit-tests
Change-Id: I8956296d39c98ce8c7dd0a703b240530d8ad48db
This patch introduces GWP-ASan system properties and environment
variables to control the internal sampling rates of GWP-ASan. This can
be used for:
1. "Torture testing" the system, i.e. running it under an extremely
high sampling rate under GWP-ASan.
2. Increasing sampling remotely to allow further crash report
collection of rare issues.
There are three sets of system properites:
1. libc.debug.gwp_asan.*.system_default: Default values for native
executables and system apps.
2. libc.debug.gwp_asan.*.app_default: Default values for non-system
apps, and
3. libc.debug.gwp_asan.*.<basename/app_name>: Default values for an
individual app or native process.
There are three variables that can be changed:
1. The allocation sampling rate (default: 2500) - using the environment
variable GWP_ASAN_SAMPLE_RATE or the libc.debug.gwp_asan.sample_rate.*
system property.
2. The process sampling rate (default: 128 for system apps/processes, 1
for opted-in apps) - using the environment variable
GWP_ASAN_PROCESS_SAMPLING or the libc.debug.gwp_asan.process_sampling.*
system property,
3. The number of slots available (default: 32) - using the environment
variable GWP_ASAN_MAX_ALLOCS or the libc.debug.gwp_asan.max_allocs.*
system property.
If not specified, #3 will be calculated as a ratio of the default
|2500 SampleRate : 32 slots|. So, a sample rate of "1250" (i.e. twice as
frequent sampling) will result in a doubling of the max_allocs to "64".
Bug: 219651032
Test: atest bionic-unit-tests
Change-Id: Idb40a2a4d074e01ce3c4e635ad639a91a32d570f
Two edge cases were found in aosp/2038947:
1. realloc(p, 0) == free() and returns nullptr. Previously, we just
returned a new pointer.
2. If the malloc() part of realloc() fails (e.g. when the size of the
allocation is 1 << 56), then the old memory shouldn't be destroyed.
Bug: N/A
Test: Covered using atest bionic-unit-tests using aosp/2038947.
Change-Id: Ibafc752787129922a1e0323ffa14221d6a14f108
When calling android_mallopt using M_INITIALIZE_GWP_ASAN, nothing
was being returned. Fix this, add a test, and also refactor the
code a bit so dynamic and static share the same code.
Test: Unit tests pass in dynamic and static versions.
Test: Passed using both jemalloc and scudo.
Change-Id: Ibe54b6ccabdbd44d2378892e793df393978bc02b
Unnecessary include, and the file was deleted with upstream changes.
Bug: N/A
Test: cd external/gwp_asan && atest
Change-Id: Id8facff0c5e382aa639ce158b7b5862ce157aa25
Exports GWP-ASan allocator information callbacks to libdebuggerd so that
tombstoned can get information from the GWP-ASan allocator in the case
of a crash.
Bug: 135634846
Test: atest bionic-unit-tests
Change-Id: Ie16426af55602fb2a76c4e69217773354c365843
The notification that GWP-ASan is enabled causes ART tests to break.
Remove the log for now.
Bug: 135634846
Bug: 149790891
Test: (Attempt to fix the ART tests).
Change-Id: I8a7751a838a64f160b3b7b9f07752bb64644b9db
This patch enables GWP-ASan with process sampling.
**Note**: If you are visiting this patch because this broke a test or
otherwise is causing failures, please contact mitchp@ directly (or
respond to this patchset). GWP-ASan is designed to cause heap-based
memory safety bugs to manifest in SEGV on a sampled basis.
Bug: 135634846
Test: atest bionic-unit-tests gwp_asan_unittest
Change-Id: I58ca9373def105fdd718cf283482b3220b770698
GWP-ASan + heapprofd don't currently play nice together in some
circumstances. heapprofd thinks it's still an only child, and refuses to
accept the existence of its little brother, GWP-ASan.
If GWP-ASan is installed before heapprofd, then heapprofd is *required*
to respect that libc has a favourite child. If an allocation/free is passed
to heapprofd, then heapprofd *must* (eventually) pass that allocation/free to
GWP-ASan. If heapprofd doesn't do this, then a free() of a GWP-ASan
allocation can be passed to the system allocator.
This can happen in two places right now:
1. The heapprofd hooks simply clobber any trace of what was
previously in the default_dispatch_table when enabled through the
heapprofd signal.
2. Heapprofd can die when the system is under significant pressure.
Some pipes can timeout, which ends up in the client calling ShutdownLazy()
-> mallopt(M_RESET_HOOKS) -> DispatchReset(). This also clobbers any
trace of the previous default_dispatch_table.
To fix both these problems, we fix heapprofd to restore the previous
default_dispatch_table whenever either circumstance happens. We do some
tricky copying to avoid race conditions on the malloc_dispatch_table in
fixing #1.
Bug: 135634846
Test: Run HeapprofdEndToEnd.NativeProfilingActiveAtProcessExit/ForkMode
a significant number of times with large amounts of system pressure (I
just run bionic-unit-tests-scudo in parallel). You will see some test
failures where heapprofd died due to system pressure, but never a death
from the allocator. Tests should never fail when the system isn't under
immense pressure.
Change-Id: I20ab340d4bdc35d6d1012da5ee1a25634428d097
The WriteProtected mutator for __libc_globals isn't reentrant.
Previously we were calling __libc_globals.mutate() inside of GWP-ASan's
libc initialisation, which is called inside the __libc_globals.mutate().
This causes problems with malloc_debug and other malloc shims, as they
fail to install when GWP-ASan is sampling their processes.
Bug: 135634846
Test: atest bionic
Change-Id: Iae51faa8d78677eeab6204b6ab4f3ae1b7517ba5
This patch introduces GWP-ASan - a sampled allocator framework that
finds use-after-free and heap-buffer-overflow bugs in production
environments.
GWP-ASan is being introduced in an always-disabled mode. This means that
GWP-ASan will be permanently disabled until a further patch turns on
support. As such, there should be no visible functional change for the
time being.
GWP-ASan requires -fno-emulated-tls wherever it's linked from. We
intentionally link GWP-ASan into libc so that it's part of the initial
set of libraries, and thus has static TLS storage (so we can use
Initial-Exec TLS instead of Global-Dynamic). As a benefit, this reduces
overhead for a sampled process.
GWP-ASan is always initialised via. a call to
mallopt(M_INITIALIZE_GWP_ASAN, which must be done before a process is
multithreaded).
More information about GWP-ASan can be found in the upstream
documentation: http://llvm.org/docs/GwpAsan.html
Bug: 135634846
Test: atest bionic
Change-Id: Ib9bd33337d17dab39ac32f4536bff71bd23498b0
