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
If a process is failing due to out of memory, some code calls
android_set_abort_message with a nullptr. Specifically, the libc++
library std::terminate can call do this. In this case, put a
null in the abort message.
Test: Call with nullptr and verify the code does not crash.
Test: Modified crasher to set an abort message and set a null abort
Test: message. Ran both, verified the abort message displays in
Test: first case, and doesn't display in the second case.
Change-Id: Ia9250f47e4537853ce93bbb20b35915a78caa502
There are other options here (see the code comment for details), but
this is the least effort/least disruptive for now.
Bug: http://b/227498625
Test: treehugger
Change-Id: I33be6fbfc022238de2f1846a69af1e712a9d6391
This is important for enabling the error about unsupported TLS
relocations to local symbols. The fast path tends to skip this error,
because it fails during lookup_symbol(). Add a test for this error.
I didn't see a performance regression in the linker_relocation
benchmark.
Bug: http://b/226978634
Test: m bionic-unit-tests
Change-Id: Ibef9bde2973cf8c2d420ecc9e8fe2c69a5097ce2
This is exactly what it is testing for.
Original warning:
bionic/tests/stdio_test.cpp:370:47: error: '%n' specifier not supported on this platform [-Werror,-Wformat]
EXPECT_DEATH(snprintf(buf, sizeof(buf), "a %n b", &i), "%n not allowed on Android");
~^
Test: presubmit
Bug: 219872355
Change-Id: I6e378722b2d681cf64f4cf31ef000bd28203b00d
The kernel MTE mode auto-upgrade feature (see mte_tcf_preferred) allows
silent auto-upgrade of Async MTE mode to Asymm or Sync depending on the
OS settings. Relax the tests to allow either Sync or Async faults when
requesting Async mode, and only Sync faults when requesting Sync.
Also tighten the MTENote test to check that both system allocator and
prctl are off when MTE is disabled.
Bug: 214622342
Test: bionic-unit-tests on fvp with all variations of
/sys/devices/system/cpu/cpu*/mte_tcf_preferred=(async|asymm|sync)
Change-Id: I77a92789d6b330742d00b08c9f0fecc3a6c8fca6
Bug: http://b/218788252
IR verifier too strict for ifunc resolver that accept parameters. This
is only exposed with Thin LTO. The error is:
IFunc resolver has incorrect type
i32 ()* @_Z5hwcapv
Test: mmma GLOBAL_THINLTO=true bionic
Change-Id: Ifed4041ee8557ba1a5eb7a5a82f54b5ca5c79161
Bug: http://b/218788252
Even though a resolver can return any pointer, LLVM IR verifier now
checks that the resolver returns a pointer to the ifunc's function type.
Test: m GLOBAL_THINLTO=true libtest_ifunc_variable_impl.so
Change-Id: I7d87ffcf50bab1d61b01328907e036c51feb6a0f
dup2(2) is a no-op if the new and old fds are equal, but it's pretty
clear that any useful caller in the posix_spawn(3) context wants us to
clear O_CLOEXEC even if we don't actually "move" the fd.
Bug: https://www.austingroupbugs.net/view.php?id=411
Test: treehugger
Change-Id: I5ce1a1f9216df5afd295cc9e35b84527873e9541
Not sure how treehugger missed this, but "growler" followed up pretty
quickly, so that's something...
Bug: http://b/219758263
Test: treehugger
Change-Id: I8e4afa31aee975740d10eb2acec51d2f4f1fa414
We don't want expected crashes showing up in the automated crash
reporting!
Bug: http://b/210932139
Test: treehugger
Change-Id: I6b232f0808cdcd39739f249236177cabc40669b1
Currently, the ELF note parsing in the loader is not permissive. This
patch relaxes the restrictions on the bits of the ELF note that could be
extended in the future.
This may allow more MTE options in apexes. If we add some extra metadata
bit (say, in bit 5) in the future, and then build MTE into every apex,
we don't want it to crash on Android 13 devices (we'd much rather it
just be a no-op).
Remove the (unused anywhere) NT_MEMTAG_DEFAULT and call it
NT_MEMTAG_NONE.
And finally, make the tests work on bionic-unit-tests-static. We
previously didn't deploy the test binaries, so add them as a data
dependency.
Bug: N/A
Test: atest bionic-unit-tests-static
Change-Id: I13530faad55c719c6eb848297f8ce378e18afbfc
musl doesn't have fortify, and is missing the *_chk symbols to allow
the tests to compile.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I9a1d2dfe19db219cd2c5a6dc39cb5d08ed0e4369
Musl doesn't provide the resolv b64_* functions, but adb uses them.
Export them from bionic.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I37837e6179a15754d4cbd89e67649df9dea9d9f1
Musl doesn't provide the execinfo function. Export the from bionic.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I0361b84b0160d419cd857f5bb1314a58d0a69234
We've added mallinfo and mallinfo2 to musl, enable the bionic tests
for it. Also modify the comparison test to explicitly cast the
mallinfo fields to size_t, as they are ints in musl.
Bug: 190084016
Test: bionic-unit-tests-glibc --gtest_filter=malloc.*
Change-Id: Ib2a1d6cf698de817c314a61fe29fda85edabb9ed
Fix references to symbols that don't exist in musl in the bionic
benchmarks, and disable the header tests for musl.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I6b1964afa4a7b6e6a4812e9f2605fcfc2fae9691
The first time should_trace() returns true, bionic_trace_begin() calls
open() on trace_marker.
The problem is that open() can call bionic_trace_begin(). We've observed
this happening, for example when:
* fdtrack is enabled. dlopen("libfdtrack.so") can be used to enable
fdtrack on a process.
* ThreadA is busy unwinding inside fdtrack and is holding an fdtrack
internal mutex.
* ThreadB calls bionic_trace_begin() for the first time since the
property "debug.atrace.tags.enableflags" contains ATRACE_TAG_BIONIC.
* ThreadB calls open("/sys/kernel/tracing/trace_marker"). Since fdtrack
is enabled, ThreadB tries to do unwinding as well.
* ThreadB, inside fdtrack's unwinding tries to grab the same mutex that
ThreadA is holding.
* Mutex contention is reported using bionic_systrace, therefore
bionic_trace_begin() is called again on ThreadB.
* ThreadB tries to grab g_lock in bionin_systrace.cpp, but that's
already held by ThreadB itself, earlier on the stack. Therefore
ThreadB is stuck.
I managed to reproduce the above scenario by manually pausing ThreadA
inside unwinding with a debugger and letting ThreadB hitting
bionic_trace_begin() for the first time.
We could avoid using g_lock while calling open() (either by releasing
g_lock and reacquiring it later, or by using atomics), but
bionic_trace_begin() would try to call open() again. In my tests, open()
does not call bionic_trace_begin() a third time, because fdtrack has
reentrancy protection, but there might be another code path inside open
that calls bionic_trace_begin again (it could be racy or only happen in
certain configurations).
This commit fixes the problem by implementing reentrancy protection in
bionic_systrace.
Sample callstack from ThreadA deadlocked before the fix:
```
* frame #0: 0x0000007436db077c libc.so`syscall at syscall.S:41
frame #1: 0x0000007436db0ba0 libc.so`bionic_trace_begin(char const*) [inlined] __futex(ftx=0x000000743737a548, op=<unavailable>, value=2, timeout=0x0000000000000000, bitset=-1) at bionic_futex.h:45:16
frame #2: 0x0000007436db0b8c libc.so`bionic_trace_begin(char const*) [inlined] __futex_wait_ex(ftx=0x000000743737a548, value=2) at bionic_futex.h:66:10
frame #3: 0x0000007436db0b78 libc.so`bionic_trace_begin(char const*) [inlined] Lock::lock(this=0x000000743737a548) at bionic_lock.h:67:7
frame #4: 0x0000007436db0b74 libc.so`bionic_trace_begin(char const*) [inlined] should_trace() at bionic_systrace.cpp:38:10
frame #5: 0x0000007436db0b74 libc.so`bionic_trace_begin(message="Contending for pthread mutex") at bionic_systrace.cpp:59:8
frame #6: 0x0000007436e193e4 libc.so`NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*) [inlined] NonPI::NormalMutexLock(mutex=0x0000007296cae9f0, shared=0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:592:17
frame #7: 0x0000007436e193c8 libc.so`NonPI::MutexLockWithTimeout(mutex=0x0000007296cae9f0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:719:16
frame #8: 0x0000007436e1912c libc.so`::pthread_mutex_lock(mutex_interface=<unavailable>) at pthread_mutex.cpp:839:12 [artificial]
frame #9: 0x00000071a4e5b290 libfdtrack.so`std::__1::mutex::lock() [inlined] std::__1::__libcpp_mutex_lock(__m=<unavailable>) at __threading_support:256:10
frame #10: 0x00000071a4e5b28c libfdtrack.so`std::__1::mutex::lock(this=<unavailable>) at mutex.cpp:31:14
frame #11: 0x00000071a4e32634 libfdtrack.so`unwindstack::Elf::Step(unsigned long, unwindstack::Regs*, unwindstack::Memory*, bool*, bool*) [inlined] std::__1::lock_guard<std::__1::mutex>::lock_guard(__m=0x0000007296cae9f0) at __mutex_base:104:27
frame #12: 0x00000071a4e32618 libfdtrack.so`unwindstack::Elf::Step(this=0x0000007296cae9c0, rel_pc=66116, regs=0x0000007266ca0470, process_memory=0x0000007246caa130, finished=0x0000007ff910efb4, is_signal_frame=0x0000007ff910efb0) at Elf.cpp:206:31
frame #13: 0x00000071a4e2b3b0 libfdtrack.so`unwindstack::LocalUnwinder::Unwind(this=0x00000071a4ea1528, frame_info=<unavailable>, max_frames=34) at LocalUnwinder.cpp:102:22
frame #14: 0x00000071a4e2a3ec libfdtrack.so`fd_hook(event=<unavailable>) at fdtrack.cpp:119:18
frame #15: 0x0000007436dbf684 libc.so`::__open_2(pathname=<unavailable>, flags=<unavailable>) at open.cpp:72:10
frame #16: 0x0000007436db0a04 libc.so`bionic_trace_begin(char const*) [inlined] open(pathname=<unavailable>, flags=524289) at fcntl.h:63:12
frame #17: 0x0000007436db09f0 libc.so`bionic_trace_begin(char const*) [inlined] get_trace_marker_fd() at bionic_systrace.cpp:49:25
frame #18: 0x0000007436db09c0 libc.so`bionic_trace_begin(message="pthread_create") at bionic_systrace.cpp:63:25
```
Bug: 213642769
Change-Id: I10d331859045cb4a8609b007f5c6cf2577ff44df
Update the path to the helper binary, and run the test on non-MTE
hardware with the expectation that the bug is not detected.
Test: bionic-unit-tests
Bug: none
Change-Id: I34eb4dc46d0bacd83824d307398f7891d4806686
This was probably the least worst choice at the time, but we have toybox
readelf now, which is a much lighter-weight dependency (that we already
have for some other tests).
This is also one less use of the *renderscript* LLVM, which we'll be
wanting to finally delete soon.
Test: treehugger
Change-Id: I0e05b8f139ec6e6a425b575368f3d514b8b1cc64
It's not clear this was ever needed, it doesn't seem to make any
difference now, and these are the defaults for the obsolete renderscript
LLVM anyway, so... yeah.
This was noticed because it was causing some of our tests to be built as
C++11 rather than [the current default of] C++17.
Test: treehugger
Change-Id: I7d72b3fd58e9cf9a02048b0298eee845d19307f7
clang is smart enough to notice a variable is set but not used,
but these variable are used for testing purposes. Mark one as
unused, and convert the other to a DoNotOptimize.
Bug: 197240255
Test: Compiles without warnings.
Test: Ran unit tests on coral hwasan build.
Change-Id: Ibc873e477355a702579e5a680780c77db0c58046
It's possible for the main thread to leave the RunTimedTest
function before the waiting thread has had a chance to call e.g.
pthread_cond_timedwait(). In this case, pthread_cond_timedwait()
will access the local variable ts after its lifetime has ended. Fix
the bug by making ts a field of pthread_CondWakeupTest instead. The
lifetime of pthread_CondWakeupTest is tied to that of the waiting
thread via the pthread_join() call.
Found with HWASan + uaccess logging.
Change-Id: Iefe8deb30a367dc518013d741c425b041596b0d3
LLD supports `-z global`, unlike ld.gold, which this was previously a
workaround for.
Test: mm in test dir
Change-Id: I1f621c329accfb31912a19544e34447aff0dfa28
Explicitly test an invalid 5-byte UTF-8 sequence with mbrtoc16(3); the
fact that we weren't testing this was shown by coverage data.
Merge the surrogate pair tests in with their fewer-byte siblings to make
it clearer to a human reader that we've covered both cases.
Clear errno to make assertions about errno more convincing.
Test: treehugger
Change-Id: I485a48cc141f3e52058e2138326f3134d41b2243
This came up with POSIX recently. Doesn't seem like it matters since
everyone's had this wrong for 40 years, but "meh" --- it's a trivial
fix, and it's strictly correct even if nobody needs this, so let's just
do it...
(Geoff Clare pointed out that my app compat concern "what if someone's
relying on this bug to pass flags to the shell?" isn't relevant because
while you can indeed do that, you then can't pass a command!)
Bug: https://austingroupbugs.net/view.php?id=1440
Test: treehugger
Change-Id: I64f6440da55e2dc29d0136ee62007197d2f00d46
