With memtag_stack, each function is responsible for cleaning up
allocation tags for its stack frame. Allocation tags for anything below
SP must match the address tag in SP.
Both vfork and longjmp implement non-local control transfer which
abandons part of the stack without proper cleanup. Update allocation
tags:
* For longjmp, we know both source and destination values of SP.
* For vfork, save the value of SP before exit() or exec*() - the only
valid ways of ending the child process according to POSIX - and reset
tags from there to SP-in-parent.
This is not 100% solid and can be confused by a number of hopefully
uncommon conditions:
* Segmented stacks.
* Longjmp from sigaltstack into the main stack.
* Some kind of userspace thread implementation using longjmp (that's UB,
longjmp can only return to the caller on the current stack).
* and other strange things.
This change adds a sanity limit on the size of the tag cleanup. Also,
this logic is only activated in the binaries that carry the
NT_MEMTAG_STACK note (set by -fsanitize=memtag-stack) which is meant as
a debugging configuration, is not compatible with pre-armv9 CPUs, and
should not be set on production code.
Bug: b/174878242
Test: fvp_mini with ToT LLVM (more test in a separate change)
Change-Id: Ibef8b2fc5a6ce85c8e562dead1019964d9f6b80b
Map all stacks (primary, thread, and sigaltstack) as PROT_MTE when the
binary requests it through the ELF note.
For the reference, the note is produced by the following toolchain changes:
https://reviews.llvm.org/D118948https://reviews.llvm.org/D119384https://reviews.llvm.org/D119381
Bug: b/174878242
Test: fvp_mini with ToT LLVM (more tests in a separate change)
Change-Id: I04a4e21c966e7309b47b1f549a2919958d93a872
Musl doesn't have close_range, skip the test.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I7ed485f2d0ec08358c856430b7c4c45fbe45a39f
The lambda function is converted to bool instead of being called. So,
get_transparent_hugepages_supported() returns always true.
Test: check whether /sys/kernel/mm/transparent_hugepage/enabled is
accessed via strace.
Bug: http://b/233137490
Signed-off-by: Suchang Woo <suchang.woo@samsung.com>
Change-Id: I88b0d18d8ceb2300482043391eed4ae7041866ca
Add backtrace_size for only backtracing a single size.
Add backtrace_min_size to set the minimum value of size to backtrace.
Add backtrace_max_size to set the maximum value of size to backtrace.
Documented the new options.
Test: New unit test pass.
Change-Id: I1a773737910cd4bc2af9546547b3a2740bbcb22b
Modify the tests that require a single filename, to use a filename
that has the pid as part of the name. This allows multiple different
versions of the test to run on the same machine, and allows
each test to be run at the same time.
Test: Ran unit tests on device.
Test: Ran the unit tests 100 times, no failures.
Change-Id: Ia38483049e7b66bd3da824bcd484c03e46f85280
The new object incorporates all Android specific knowledge into
a single place and makes everything simpler.
Fixed a bug where if backtrace_full was enabled, the AddBacktrace
function would always set the size to the maximum number
of frames instead of the actual number of frames.
Added a new smoke system tests for backtrace_full.
Modified the smoke test to do a malloc/free, so it's really
a smoke test.
Bug: 232575330
Test: Unit tests pass on device.
Test: Verify the full backtrace actually produces valid backtraces.
Test: Run bionic-unit-tests with backtrace_full enabled.
Test: Run bionic-benchmarks --benchmark_filter=stdlib_malloc_free_decay1/512
Change-Id: I23128a73a8691007e1c7f69e0c99bb4dcd713db8
This test tried to be lazy and test both getmntent() and getmntent_r()
in the same test, but that led to an implicit assumption that /proc
isn't the first mount returned.
This new version is quite a bit more thorough than the old. It does
assume that the mount list doesn't change while the test is running, but
that seems like a reasonable assumption to make during CTS?
Bug: https://issuetracker.google.com/230228681
Test: treehugger
Change-Id: I5c5f0b86ae1c4df9a2ce69d48e1c3accb42c687b
(cherry picked from commit 1e393b0699)
This test tried to be lazy and test both getmntent() and getmntent_r()
in the same test, but that led to an implicit assumption that /proc
isn't the first mount returned.
This new version is quite a bit more thorough than the old. It does
assume that the mount list doesn't change while the test is running, but
that seems like a reasonable assumption to make during CTS?
Bug: https://issuetracker.google.com/230228681
Test: treehugger
Change-Id: I5c5f0b86ae1c4df9a2ce69d48e1c3accb42c687b
The new option is named check_unreachable_on_signal. It is meant
to duplicate dumpsys meminfo --unreachable <PID> for non-java
processes. When enabled, a user can send a signal to a process
which will trigger the unreachable check on the next allocation
call.
Added new unit tests.
Test: New unit tests pass.
Test: Enabled for the entire system, then dumped on the netd
Test: process and also system_server.
Change-Id: I73561b408a947a11ce21a211b065d59fcc39097b
See:
https://man7.org/linux/man-pages/man2/close_range.2.html
Note: 'man close_range' documents 'flags' as unsigned int,
while glibc unistd.h as just 'int'. Picking 'int' to match glibc,
though it probably doesn't matter.
BYPASS_INCLUSIVE_LANGUAGE_REASON=man is a cli command
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1e2d1c8edc2ea28922d60f3ce3e534a784622cd1
The libmemunreachable library looks through memory to determine
if pointers are leaked. Unfortunately, the malloc debug code
stores the original pointer in data structures, so it looks like
pointers are still in use. The fix is to mangle the pointers
stored in memory so that it doesn't trick the library into thinking
they are live.
Test: All unit/system tests pass.
Test: Ran libmemunreachable and verified leaks show up.
Change-Id: Ic40a0a5ae73857cde936fd76895d88829686a643
