ANDROID_DLEXT_WRITE_RELRO was inadvertently writing out the RELRO
section of all libraries loaded during a given dlopen() call instead of
only the main library; since the other libraries are loaded at
unpredictable addresses this additional data is rarely useful.
Fix this to only happen when the
ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE flag is being used.
Bug: 128623590
Test: DlExtRelroSharingTest.CheckRelroSizes
Change-Id: I05e8651d06ce2de77b8c85fe2b6238f9c09691ad
We switched to genrules already, and the lack of `set -e` in the script
means that no-one's even noticed that this script has been failing since
then...
Test: N/A
Change-Id: Ie57cc97ab4e1003a106d4667cd404d22f0ee68a2
malloc_common_dynamic.cpp is compiled into both libc.so and
libc_scudo.so. When compiled for libc_scudo.so, it doesn't try to load
libc_malloc_* libs from the runtime linker namespace. This is because,
unlike libc.so which is shared from the runtime APEX, libc_scudo.so is
copied to any APEX that it needs. Furthermore, libdl_android which
provides android_get_exported_namespace is not available for vendors. So
the vendor variant of libc_scudo.so can't anyway locate the runtime
namespace.
Bug: 130213757
Bug: 122566199
Test: `m libc_scudo libc_scudo` is successful
Test: inspect the built library to see if it has reference to
android_get_exported_namespace
Merged-In: I4c41de361fdb3fa34b95218923f4ce4e9c010f9e
Change-Id: I4c41de361fdb3fa34b95218923f4ce4e9c010f9e
(cherry picked from commit ff94a13d2d)
/system/lib/libc.so is a symlink to libc.so in the runtime APEX.
libc_malloc_* libraries are bundled with libc.so because they share
implementation details.
However, since libc.so is loaded in the default namespace where the
runtime APEX path (/apex/com.android.runtime/lib) is not accessible,
libc.so has been using libc_malloc_* from /system/lib. This is
wrong because libc.so (from the runtime APEX) and libc_malloc_* (from
the platform) may not be in-sync.
libc.so now uses android_dlopen_ext to load libc_malloc_* libraries
correctly from the "runtime" linker namespace.
Bug: 122566199
Test: bionic-unit-tests
Merged-In: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
Change-Id: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
(cherry picked from commit 4e46ac69c2)
Adding some benchmarks that keep a certain number of allocation
around. This benchmark should not be used as an absolute for determining
what is a good/bad native allocator. However, it should be used to make
sure that numbers are not completely changed between allocator versions.
Also update the malloc sql benchmark to match the same style as these
new benchmarks.
Bug: 129743239
Test: Ran these benchmarks.
Change-Id: I1995d98fd269b61d9c96efed6eff3ed278e24c97
Bug: http://b/129728267
Bug: http://b/117167374
This test is now built with XOM (because libm now uses XOM) but it
should also use libclang_rt.builtins since libgcc is not built with XOM.
Test: bionic-unit-tests-static passes (but used to segfault with XOM
exceptions without this change).
Change-Id: I0b1dfe52e48db5f5e9386c7722ecd91e155be56f
Issue:
Process is crashed near the end (startup_handshake_lock.unlock()) in
pthread_create().
The newly created child thread passes this handshake_lock unexpectedly
=> its stack is unmapped & its associated pthread_internal_t data
structure can’t be accessed.
Analysis:
The created child thread should be blocked by startup_handshake_lock.lock()
and enter __futex_wait_ex()
But if the parent thread is in the middle of startup_handshake_lock.unlock():
void unlock() {
if (atomic_exchange_explicit(&state, Unlocked, memory_order_seq_cst) == LockedWithWaiter) { // => the state is modified to Unlocked
// (a) if the child thread is back to running and pass the while() check in Lock::lock()
// (b) the child thread executes its start_routine and then pthread_exit
// (c) the stack of the child thread (where its pthread_internal_t (so the startup_handshake_lock) is located) will be unmapped
__futex_wake_ex(&state, process_shared, 1); // => when the parent thread is back to running
// the “state” & “process_shared” of startup_handshake_lock can’t be accessed (unmapped)
// so the process will be crashed
}
}
Bug: 129744706
Test: Monkey
Change-Id: I55175e8c7ebc2b3b52de8a5602def0667076b974
ANDROID_DLEXT_WRITE_RELRO was causing the GNU RELRO sections of
libraries to become corrupted if more than one library was being loaded
at once (i.e. if the root library has DT_NEEDED entries for libraries
that weren't already loaded). The file offset was not being correctly
propagated between calls, so after writing out the (correct) RELRO data
to the file, it was mapping the data at file offset 0 for all libraries,
which corrupted the data for all but one of the libraries.
Fix this by passing file_offset as a pointer the same way that
phdr_table_map_gnu_relro does.
Bug: 128623590
Test: tbd
Change-Id: I196cd336bd5a67454e89fd85487356b1c7856871
Add a new option verbose for malloc debug that is not enabled by default.
This disables all of the info log messages. It turns out these log
messages can add a measurable amount of time and can change the boot up.
Bug: 129239269
Test: Adjusted unit tests pass.
Test: Verified no messages unless verbose option used.
Change-Id: I805cb7c8ecb44de88119574e59d784877cacc383
The media processes already use scudo as their allocator. However, it
doesn't really correctly replace the normal allocation functions, so create
a set of wrappers that allow us to use scudo closer to how jemalloc is used.
This is only a temporary change, and should be removed for the next
release of Android. In that version, we will be using standalone
scudo which won't require this wrapper code.
Bug: 123689570
Test: Ran new bionic unit tests. There are failures, but only with
Test: extensions that scudo does not support.
Change-Id: I0516c23d654a9b6c69b157c5501245d2e0b3d264
There have been several changes since the file was created. Update the
file with latest build. We also sort the symbols by names when they
have the same size so that future updates are easier to review.
Bug: 124521408
Test: Build and inspect symbol ordering
Change-Id: Iedd885b9a87d882ae278a1f117f40b20d064c384
The linker_namespaces test need android_get_LD_LIBRARY_PATH function.
Bug: http://b/129479780
Test: atest CtsJniTestCases
Change-Id: Iba5f74e1e4b5b1de173150120293102524db2507
(cherry picked from commit 91b0c68009)
Symbols not intended to be accessible from apps are moved to libdl_android.so
Test: bionic-unit-tests
Bug: http://b/129387775
Change-Id: Ib8ba6147a20cf56550c9a008f66570a2d419565a
(cherry picked from commit 2d6be9a751)
