Introduce an M_SET_ALLOCATION_LIMIT enumerator for android_mallopt(),
which can be used to set an upper bound on the total size of all
allocations made using the memory allocation APIs.
This is useful for programs such as audioextractor and mediaserver
which need to set such a limit as a security mitigation. Currently
these programs are using setrlimit(RLIMIT_AS) which isn't exactly
what these programs want to control. RLIMIT_AS is also problematic
under sanitizers which allocate large amounts of address space as
shadow memory, and is especially problematic under shadow call stack,
which requires 16MB of address space per thread.
Add new unit tests for bionic.
Add new unit tests for malloc debug that verify that when the limit
is enabled, malloc debug still functions for nearly every allocation
function.
Bug: 118642754
Test: Ran bionic-unit-tests/bionic-unit-tests-static.
Test: Ran malloc debug tests and perfetto integration tests.
Change-Id: I735403c4d2c87f00fb2cdef81d00af0af446b2bb
When built with clang-r353983, the ReservedRecursiveTooSmall test fail
due to the reserved memory is now large enough for android_dlopen_ext.
Reduce the reserved memory size to agree with ReservedTooSmall test.
Test: bionic-unit-tests
Bug: 126457671
Change-Id: I3e311a3f35b0de5d028fa1b9b3681d5ec32faee8
This hasn't been particularly useful, we haven't used it consistently,
and it has caused trouble.
Test: builds
Change-Id: Ic5b5b5124af98aa8301e602fd75b0eb72a5fc7f6
The *.mountpoint targets that installs /bionic/lib/lib*.so and
/bionic/bin/linker* are no longer needed.
Now, /system/lib/lib*.so and /system/bin/linker* are simply symlinks to
the corresponding files in the runtime apex. For example,
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
This is made possible because we now activate APEXes even before the
data partition is mounted. Before the data partition mounting, the
APEXes from the system partition are ativated. After the data partition
is mounted, updated APEXes in the partition (if any) are activated. As a
result, the symlink always points to the valid path regardless of
whether /data is mounted or not.
Bug: 125549215
Test: device boots
Change-Id: Ie7d83686abe00b3c436f9f9db75d4244200a0fc9
Make the num_free_blocks calculation clearer. There are
sizeof(page->bytes) bytes available for blocks, which is equal to
(kAllocateSize - 16). The previous calculation overestimates the amount
of space by 8 or 12 bytes, but that doesn't change the result because
both kAllocateSize and block_size_ are multiples of 16.
Bug: none
Test: boot device, bionic unit tests
Change-Id: Ia880cd5abc2a7bb4e9e6a8c0441d985f4df8fdc4
The tlsdesc_resolver_dynamic function is only defined on arm64, but the
code was taking its address on all targets. (Apparently the optimizer was
removing the entire deferred_tlsdesc_relocs loop?)
Bug: none
Test: bionic unit tests
Test: add -O0 to cc_defaults in linker/Android.bp, device boots
Change-Id: I899c78018cbe82aeaca7856c9f7b04300c1d3196
It's possible and sometimes beneficial for a library to have disjoint mappings
and for other libraries to be mapped into the gap between the mappings using
ANDROID_DLEXT_RESERVED_ADDRESS. See for example the proposal for partitioning
in lld [1].
Because the find_containing_library and do_dl_unwind_find_exidx functions use
a simple bounds check to figure out whether a pointer belongs to a library
they will, given a pointer into a library mapped into the gap of a library
with disjoint mappings, return a pointer to the soinfo for the outer library
instead of the inner one, because the outer library will appear before the
inner one in the solist.
From a user perspective this means that we won't be able to unwind the inner
library's frames on 32-bit ARM with libgcc, dladdr() will return information
for the outer library given a pointer to the inner one and dlopen() et al will
use the linker namespace of the outer library when called from the inner one
(although they will usually be the same).
To make this work correctly, make it so that once find_containing_library
sees a match for the bounds check, it examines the library's PT_LOADs to
make sure that there is a mapping for the given address. This is similar
to how libgcc and libunwind_llvm already handle finding the PT_GNU_EH_FRAME
on non-ARM32 platforms [2,3]. do_dl_unwind_find_exidx is reimplemented in
terms of find_containing_library.
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html
[2] e739ac0e25/libunwind/src/AddressSpace.hpp (L523)
[3] https://android.googlesource.com/toolchain/gcc/+/master/gcc-4.9/libgcc/unwind-dw2-fde-dip.c#294
Test: /data/nativetest{,64}/bionic-unit-tests/bionic-unit-tests on walleye-userdebug
Change-Id: I368fe6ad3c470b3dff80f7d9b04253566d63a7d2
When we enable free_track option, one thread is in AddFreed->RemoveBacktrace
flow (hold free_pointer_mutex_ first and try to lock frame_mutex_), and
other thread do fork and enter PrepareFork flow (hold frame_mutex_ first
and try to lock free_pointer_mutex_), this situation may result in mutex
deadlock issue.
Bug: 127733115
Test: build pass and stress test pass
Change-Id: Ie5fcc4ef6c169372ad73d81978cfb2a726b6c03e
malloc_info needs to be per native allocator, but the code treated it
like a global function that doesn't depend on the native memory allocator.
Update malloc debug to dump the actual pointers that it has been tracking.
Test: bionic-unit-tests pass.
Test: malloc debug tests pass.
Test: malloc hook tests pass.
Change-Id: I3b0d4d748489dd84c16d16933479dc8b8d79013e
Merged-In: I3b0d4d748489dd84c16d16933479dc8b8d79013e
(cherry picked from commit a3656a98b1)
bionic has been moved to use libandroidicu instead of libicuuc.
This CL updates the unit test
Bug: 120659668
Test: m bionic-unit-tests && adb push out/target/product/walleye/data/nativetest/* /data/nativetest && adb shell /data/nativetest/bionic-unit-tests/bionic-unit-tests
Change-Id: I59a0589d18bfd6753215dc07874f3c472bd64cca
Jemalloc does not verify that the size parameter is a multiple of
alignment. Fix this since it only went into P.
Fix the unit tests, and fix malloc debug/malloc hooks to handle this
new restrictive behavior.
Bug: 126944692
Test: Ran bionic unit tests.
Test: Ran bionic unit tests with malloc hooks enabled (no new tests fail).
Test: Ran bionic unit tests with malloc debug enabled (no new tests fail).
Test: Ran malloc debug unit tests.
Change-Id: I4d50785928815679c781ca729f998454d76b9192
The upcoming compiler warns against adding string and int:
In file included from bionic/libc/bionic/strsignal.cpp:41:
bionic/libc/private/bionic_sigdefs.h:58:1: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int]
__BIONIC_SIGDEF(SIGWINCH, "Window size changed")
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bionic/libc/bionic/strsignal.cpp:40:83: note: expanded from macro '__BIONIC_SIGDEF'
#define __BIONIC_SIGDEF(signal_number, unused) [ signal_number ] = #signal_number + 3,
~~~~~~~~~~~~~~~^~~
Use array indexing index to avoid this warning.
Test: m checkbuild
Change-Id: Ib5e20edbf5bac76352df0484dd233d0621beb4e9
File descriptor confusion can result if a process is exec()d and
STDIN/STDOUT/STDERR do not exist. In those situations, the first,
second, and third files opened by the exec()d application will have FD
0, 1, and 2 respectively. Code which reads / writes to these STD* file
descriptors may end up reading / writing to unintended files.
To prevent this, guarantee that FDs 0, 1, and 2 always exist. Bionic
only currently guarantees this for AT_SECURE programs (eg, a setuid
binary, setgid binary, filesystem capabilities, or SELinux domain
transition).
Extending this to all exec()s adds robustness against this class of
bugs. Additionally, it allows a caller to do:
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);
and know that the exec()d process will reopen these file descriptors on
its own. This has the potential to simplify other parts of Android, eg
https://android-review.googlesource.com/c/platform/system/apex/+/915694
Steps to reproduce:
sleep 100 <&- >&- 2>&- & BGPID=$! && ls -la /proc/$BGPID/fd && kill $BGPID
Expected:
$ sleep 100 <&- >&- 2>&- & BGPID=$! && ls -la /proc/$BGPID/fd && kill $BGPID
[1] 3154
total 0
dr-x------ 2 shell shell 0 1970-04-17 12:15 .
dr-xr-xr-x 9 shell shell 0 1970-04-17 12:15 ..
lrwx------ 1 shell shell 64 1970-04-17 12:15 0 -> /dev/null
lrwx------ 1 shell shell 64 1970-04-17 12:15 1 -> /dev/null
lrwx------ 1 shell shell 64 1970-04-17 12:15 2 -> /dev/null
$
[1] + Terminated \sleep 100 <&- >&- 2>&-
Actual:
$ sleep 100 <&- >&- 2>&- & BGPID=$! && ls -la /proc/$BGPID/fd && kill $BGPID
[1] 16345
total 0
dr-x------ 2 shell shell 0 2019-02-28 20:22 .
dr-xr-xr-x 9 shell shell 0 2019-02-28 20:22 ..
$
[1] + Terminated \sleep 100 <&- >&- 2>&-
Test: manual (see above)
Change-Id: I3e05700a1e8ebc7fc9d192211dd9fc030cc40139
After switching libm from libgcc to libcrt.builtins, some of the symbols
are no longer getting included in libm, causing the compiler to complain
about missing symbols from the version script. Explicitly export them in
libc (since libm depends on libc).
Bug: 122993571
Test: m checkbuild
Test: bionic-unit-tests
Change-Id: Ie91765874d20df605f557b1a8c4236619553c549
Bug: 125891203
Test: Verify that setting the program property to "" doesn't trigger
Test: heapprofd.
Change-Id: Id27cbb92c7a120d02151e29be993f369230c2de8
Introduce a new flag ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE which
instructs the linker to use the reserved address space to load all of
the newly-loaded libraries required by a dlopen() call instead of only
the main library. They will be loaded consecutively into that region if
they fit. The RELRO sections of all the loaded libraries will also be
considered for reading/writing shared RELRO data.
This will allow the WebView implementation to potentially consist of
more than one .so file while still benefiting from the RELRO sharing
optimisation, which would otherwise only apply to the "root" .so file.
Test: bionic-unit-tests (existing and newly added)
Bug: 110790153
Change-Id: I61da775c29fd5017d9a1e2b6b3757c3d20a355b3
