Before aosp/1086558, this was needed, since we would have
_USING_LIBCXX defined, yet <atomic> was not available, so we'd run
into compiler issues. After that change, we're using
__has_include(<atomic>) so this is no longer an issue.
Test: build
Change-Id: Ia81d343000e7d90f07422120fc1e1eb5becb01aa
These hooks notify the HWASan runtime library whenever a library is loaded
or unloaded so that it can update its shadow memory.
Bug: 138159093
Test: walleye_hwasan-userdebug boots with+without https://reviews.llvm.org/D65770
Change-Id: I6caf2a6540ed2c0d94db444e806a3c7ba504cabb
Bionic creates a single thread mapping to hold a thread's stack and static
TLS memory. Use PR_SET_VMA_ANON_NAME to name this region
"stack_and_tls:tid". dumpsys meminfo can report this region as "Stack"
memory.
The main thread's memory is instead named stack_and_tls:main, and the VMA
is renamed to stack_and_tls:main in a post-fork child.
For the main thread, and threads using pthread_attr_setstack, Bionic still
creates the stack_and_tls mapping, but it only has TLS memory in it.
Bug: http://b/134795155
Test: run "dumpsys meminfo" and verify that this CL increases the reported
stack memory usage from about 4MB to 21MB.
Change-Id: Id1f39ff083329e83426130b4ef94222ffacb90ae
Merged-In: Id1f39ff083329e83426130b4ef94222ffacb90ae
A bit of over-reliance on implementing pthread_cond_clockwait() in
terms of existing functions ended up with a bug that if the condition
variable was initialized to use CLOCK_MONOTONIC, then
pthread_cond_clockwait() would do the wrong thing.
This change corrects that and adds a test for this case.
Test: new and existing tests pthread_cond unit tests
Change-Id: I708d5dfbef95a67678db56dceda011f2f8fd1c5c
snprintf always calls free (on a null pointer) in its epilogue, which
results in infinite recursion if free calls a function that calls
bionic_trace_begin (e.g. when perfetto attempts to lock a mutex in
RecordFree).
Bug: http://b/137284735
Test: treehugger
Change-Id: I51c5b32e8f4e394be4602e06c7b94797df73c37b
Note that unlike the oem_ range that is used for the vendor
partitions, we do not create oem_<n> entries for these new reserved
ranges; they will only appear in getpwent()/getgrent() if there is an
entry in the corresponding passwd/group file.
Bug: 73062966
Test: can load AIDs from partitions other than vendor
Test: bionic-unit-tests
Change-Id: Ifcbbf202894adff948eaaba2a59e25c993611140
On systems where the tcache is disabled, the tcache clear option will
fail, and not really do a purge.
Bug: 137037462
Bug: 136236080
Test: Built taimen as malloc svelte and verified the M_PURGE mallopt
Test: call failed before this fix and passes afterwards.
Change-Id: Ib30e5f3e083a9c6d046adff30f2aa7eacaf6df10
__builtin_*_chk will emit warnings when things are trivially broken.
Emitting errors instead is probably better (and we can be a bit smarter
about how we emit code for trivially safe cases.)
Bug: 131861088
Test: checkbuild + bionic-unit-tests on blueline
Change-Id: I33957ad419922d0760304758ecb9bc8ad33e0b64
Plain __ for generated syscalls didn't mean it was a hidden symbol, it
just meant "please don't use this". We added ___ to signify that a
hidden symbol should be generated, but then we added the map files
anyway so you now have to explicitly export symbols. Given that, this
convention serves no particular purpose so we may as well just use the
nicer names have everything look the same.
Test: treehugger
Change-Id: If424e17a49c36f4be545f5d283c4561a6ea9c7ea
This also adds _2-variants for these functions, for extra glorious
checking
Bug: 131861088
Test: mma
Change-Id: I80475ff4bb220c0c47894e9532426f53412f176f
In an attempt to make bionic's reporting of users and groups more
accurate, this change makes the user / group functions do the
following:
1) Fail to query a uid/gid for a secondary user when the uid/gid
doesn't exist. Currently bionic would return successfully but with
a empty string for the name.
2) Fail to query a platform uid/gid, except a limited pre-allocated
set for a secondary user, as these are not used by second users.
3) Fail to query uids for all users for the GID-only app ranges:
CACHE_GID, EXT_GID, EXT_CACHE_GID, SHARED_GID.
4) Fail to query gids in SHARED_GID range for secondary users, as
these GIDs are only allocated for the first user.
5) Use "u#_a#_ext" and u#_a#_ext_cache" for EXT_GID and EXT_CACHE_GID
ranges. This both allows querying based on these names and
returning these names for the appropriate uids/gids.
This also consolidates the tests for better readability.
Test: these unit tests, boot
Change-Id: I59a1af0792e7806d423439582e56ce7f9f801c94
getpwnam_r() and getpwuid_r() clobber the storage used by getpwnam()
and getpwuid(). This isn't likely to be a big issue, but since we do
this right for the group functions, fix this as well as add a test.
Both use more space in buf than is actually required, but well below
their sysconf() suggested values, so we accept that to keep the code
concise.
Add tests for dealing with unaligned input buffers, particularly for
getgrnam_r() and getgrgid_r(), as they require alignment but this
wasn't being tested.
Refactor common initialization code for both passwd and group state
structs.
Remove extraneous null pointer checks; the values they were testing
were offsets of a previous pointer, so guaranteed to never actually be
null. If the underlying pointer is actually null, we're beyond repair
anyway, so accept that we'll crash.
Test: pwd/grp unit tests
Change-Id: I60c4d00e9ab3cf55daf8314c5029fd914025b696
Added get_malloc_leak_info and free_malloc_leak_info for arm 32 bit
only so that the kindle app will continue to run.
Bug: 132175052
Test: Ran kindle app, read pdf file. Verified libKindleReaderJNI.so
Test: is loaded in memory properly.
Change-Id: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
Merged-In: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
(cherry picked from commit 235f35a266)
Also change the names of some of the functions to make it very obvious
that the functions being called are in je code.
Write new test to make sure mallinfo and malloc_info match.
Bug: 131864803
Test: New unit tests pass (along with all other bionic unit tests).
Change-Id: I26eda7e64f57a8c56cc8d70e3ed6a29dcb87f630
Merged-In: I26eda7e64f57a8c56cc8d70e3ed6a29dcb87f630
(cherry picked from commit 125d32cb46)
Bug: 131362671
Test: Ran bionic unit tests.
Test: Wrote a test that did a purge and verified that the tcache->ncached
Test: number went from 3 to 0. Also verified that mallinfo reflects the
Test: cached entries being flushed.
Change-Id: I64e35618fa3b523cf29bdaceedef676abe440dd3
Similar to the way we handle LIBC_DEBUG_MALLOC_OPTIONS
(bug 68003719), filter LIBC_HOOKS_ENABLE when we cross a
security boundary. This prevents modifying the allocation
behavior of a privileged program.
Introduced in
db478a6274%5E%21/#F0
(bug 30561479)
Test: compiles and boots
Change-Id: I59a7c224734b0991fd62efb45ab599dab8570723
For security reasons, when a binary is executed which causes a security
transition (eg, a setuid binary, setgid binary, filesystem capabilities,
or SELinux domain transition), the AT_SECURE flag is set. This causes
certain blacklisted environment variables to be stripped before the
process is executed. The list of blacklisted environment variables is
stored in UNSAFE_VARIABLE_NAMES. Generally speaking, most environment
variables used internally by libc show up in this list.
Commit 02586a2a34 ("linker: the
global group is added to all built-in namespaces", Aug 2017) added
support for the environment variable LD_CONFIG_FILE. This debug build
only feature allows the caller to specify the path to the loader
configuration file. Like other linker environment variables, setting
this variable allows the calling process to control executed code of the
called process, which has security implications (on debuggable builds
only).
Add LD_CONFIG_FILE to UNSAFE_VARIABLE_NAMES. This has the effect of
stripping, on all build types, the LD_CONFIG_FILE environment variable.
This has three advantages:
1) Prevents security bugs should LD_CONFIG_FILE ever be inadvertantly
exposed on a production build.
2) Makes the behavior of userdebug and user builds more similar, helping
prevent build-type dependent bugs where someone may come to rely on this
debug-only feature.
3) Protect droidfood users against malicious applications which can
trigger a security transition, eg, the execution of crash_dump or the
renderscript compiler.
Alternative considered but rejected:
If we treated LD_CONFIG_FILE like LD_PRELOAD, we could expose this on
all build types, and remove the build-type dependent behavior. But this
is contrary to enh's Aug 02 2017 guidance at
https://android-review.googlesource.com/c/platform/bionic/+/449956
i'm still uncomfortable about LD_CONFIG_FILE because i'd like
to be reducing the number of environment variables that affect
the linker in P rather than increasing them.
Test: atest CtsBionicTestCases
Test: atest linker-unit-tests
Change-Id: I82d286546ee079b5cde04428dc89941c253c2d20
Devices launched before Q may be using OEM defined AID that are not in
the OEM_RESERVED ranges. Those devices should be allowed to keep using
legacy oem AID values given it may not be possible to upgrade the
userdata and persist files through OTA.
Bug: 131095318
Test: bionic-unit-tests
Change-Id: I73fc0c452420be5287adcacb36a1e772acc9bb3e
We loop through android_ids in many functions, but this can be
consolidated into find functions.
Test: bionic-unit-tests
Change-Id: I70c423affe49090a93e999c72bb4c84a068de5d8
FreeBSD, glibc, and musl have all implemented C11 threads at this
point. POSIX is looking at how to align with it. Probably time to jump
on the bandwagon ourselves...
Implemented in the same style as <termios.h> so we can provide this
functionality even on older API levels. This does mean that this is
strictly more expensive than calling pthread functions directly.
Although this isn't in POSIX yet, assume that it's going to be basically
the same as C11 and add the header test anyway. We should revisit this
when POSIX actually adds <threads.h>.
Test: new tests
Change-Id: I8602d67ce71ca7f8ed1529daa0a8ea1feb083dd6
Ensure we call realloc@plt rather than (as was previously happening)
inlining realloc into reallocarray, which makes the allocation invisible
to ASan.
Bug: http://b/129989984
Test: objdump
Change-Id: If8a43cba11aa5a2f2f62bacd02ef6ef4032e0dbb
Add a couple of comments explaining that a mutex can be freed during
the unlock call, immediately after the unlock's atomic exchange call but
before its futex wakeup call.
Bug: http://b/129744706
Test: bionic unit tests
Change-Id: I2d290ebde880f46866098d022720896039e7022e
For a recursive or errorcheck PI mutex, the old_owner variable wasn't
being initialized. As a result, unlocking a doubly-locked recursive
mutex owned by another thread decremented the mutex counter. Instead, the
unlock call should fail with EPERM.
Bug: http://b/130841532
Test: bionic-unit-tests
Test: bionic-unit-tests-glibc --gtest_filter='pthread.pthread_mutex_lock*'
Change-Id: I37adb094cb2ce8d51df7b4f48e8d6bc144436418
Bug: 130028357
Test: malloc_hooks unit tests.
Test: Enable backtrace for mediaserver, run dumpsys media.player -m
Test: Enable backtrace for calendar, run am dumpheap -n <PID> <FILE>
Change-Id: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
Merged-In: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
(cherry picked from commit 3aadc5e80a)
Remove this global variable and change the setting of it to non-zero
to a call to android_mallopt.
In addition, change the initialize function to use pass a bool* instead of
int*.
Bug: 130028357
Test: Ran malloc_debug/malloc_hooks/perfetto tests.
Change-Id: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
Merged-In: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
(cherry picked from commit 5225b342f0)
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)
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
The previous refactor left a double call to the initialization of
the loaded hooks. Remove the unnecessary call.
Bug: 129239269
Test: All unit tests pass. No double printing of init messages.
Change-Id: Ie980f2383c75d69f8b06bf9a431bb59caef21188
This makes it easier for tools to find the mapping. I am planning
to use this in crashpad to add HWASAN reports to the minidump.
Bug: http://crbug.com/crashpad/287
Change-Id: I600e551ef26d6ff62849319365d77912afa82fde
We regressed on this recently: code under the upstream-* directories has
_PATH_BSHELL defined as a call to __bionic_get_shell_path(). In our own
code, we may as well just call it directly.
Bug: https://issuetracker.google.com/129030706
Test: ran tests
Change-Id: Ic2423f521272be95e67f94771772fe8072636ef0
__hwasan_init() was segfaulting when called from here because it
was calling into libc functions which required more of libc to be
initialized. Instead, call __hwasan_init_static(), which does a
minimal amount of initialization for statically linked executables,
just enough that we can run instrumented code. __hwasan_init() itself
will end up being called later (most likely from a global ctor)
after libc is fully initialized.
We'll need to wait for LLVM r352816+r352823 to land in our toolchain
before landing this.
Change-Id: I12ffc7e08f6dd161e4ff2088f8d56265af7baedf
Bug: 128872105
Test: Ran the android_mallopt.set_allocation_limit_multiple_threads test
Test: a thousand times on taimen.
Change-Id: I67a474c53cd6eda8106feac99aee8e7b0bee1254
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
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)
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
Bug: 125891203
Test: Verify that setting the program property to "" doesn't trigger
Test: heapprofd.
Change-Id: Id27cbb92c7a120d02151e29be993f369230c2de8
Gold isn't emitting these symbols, so we don't necessarily have the
support for them (gold is still the default for most architectures in
the NDK).
Test: bionic static unit tests
Bug: None
Change-Id: Ifc360cb6c26571fb3f0309adb0faf0af7ee5b36f
The log priorities and ids are in an NDK header, available to everyone.
Move CHECK into its own header for now. This would be better if it was
more like the <android-base/logging.h> CHECK family, but I don't have an
easy way to do that without lots of copy & paste, so punting for now.
Bug: https://issuetracker.google.com/issues/119713191
Test: boots
Change-Id: I4566be8a0a024fede0e2d257c98b908ec67af2a8
All of the heapprofd code assumes that it's the only hook that
has been enabled. Enforce that by disallowing heapprofd from
enabling if malloc debug or malloc hooks have been enabled.
Test: Ran all unit tests (bionic/malloc hooks/malloc debug/perfetto).
Test: Enabled malloc debug ran perfetto integration tests and verified
Test: that an error message goes to the log.
Change-Id: I506fbf1c5b8e4052855531fa0d161f5de06e6c1a
The pieces:
- The malloc common shared by static and dynamic code (malloc_common.cpp).
- The code for shared libraries that includes any dlopen'ing
(malloc_common_dynamic.cpp).
- The implementation of perfetto's heapprofd (malloc_heapprofd.cpp).
This makes it easier to see what's going on in the many different areas.
It should also make it easier to add the allocation capping option.
Other related changes:
- Update the unit tests for android_mallopt. All of the current options
don't work on static binaries, so make sure that is reflected in the test.
- A few names changes to make sure that all code is consistent.
Test: Ran tests (malloc hooks/malloc debug/perfetto/bionic unit tests).
Change-Id: I0893bfbc0f83d82506fac5d1f37cf92fbdef6f59
When the linker is invoked on itself, (`linker64 /system/bin/linker64`),
the linker prints an error, because self-invocation isn't allowed. The
current method for detecting self-invocation fails because the second
linker instance can crash in a constructor function before reaching
__linker_init.
Fix the problem by moving the error check into a constructor function,
which finishes initializing libc sufficiently to call async_safe_fatal.
The only important thing missing is __libc_sysinfo on 32-bit x86. The aux
vector isn't readily accessible, so use the fallback int 0x80.
Bug: http://b/123637025
Test: bionic unit tests (32-bit x86)
Change-Id: I8be6369e8be3938906628ae1f82be13e6c510119
Instead of every function being its own atomic, have a single
pointer that can be used to flip all pointers at once. This avoid cases
where the set of pointers can be in an partial switched state.
Also fix a few inconsistent naming of functions in the file.
Test: Ran unit tests (malloc debug, malloc hooks, perfetto).
Change-Id: I3f66da395414586a3fa87874d80dcdf5f702ed39
Merged-In: I3f66da395414586a3fa87874d80dcdf5f702ed39
(cherry picked from commit 77184aedaf)
Before this CL bionic did the following:
* Finds the ICU .dat file with scandir()
* Extracts the ICU version number from the file name. e.g. _63
* dlopen() libicuuc
* dlsym() necessary symbols, e.g. <symbol name>_<icu version>
Right now such ICU symbols are stored in libandroidicu.so and suffixed
with "_android", so it is responsible for "redirecting" to functions
with approriate version and we do not need to lookup the version on our
own. libicuuc is still available for NDK (and apps), and libandroidicu is
a subset of libicuuc and libicui18n.
After this CL bionic will do the following:
* dlopen() libandroiicu
* dlsym() <symbol_name>_android (without specific version suffix)
Bug: 122822987
Test: cts-tradefed run cts-dev -m CtsBionicTestCases
Change-Id: Iabd9f35b9c3462739fd2b18e60dcdc3e202031ac
On http://b/122082295 we had this abort:
12-27 15:29:31.237 10222 10814 10848 F libc : invalid pthread_t 0xb1907960 passed to libc
This wasn't super helpful. We can do better. Now you get something like
this instead:
03-27 02:34:58.754 25329 25329 W libc : invalid pthread_t (0) passed to pthread_join
Test: adb shell crasher
Bug: http://b/123255692
Change-Id: I1d545665a233308480cc3747ec3120e2b6de0453
* changes:
Implement dynamic TLS accesses and allocation
Implement TLS_DTPMOD and TLS_DTPREL relocations
Ignore DT_TLSDESC_GOT / DT_TLSDESC_PLT
Disable the dlfcn.dlopen_library_with_ELF_TLS test
Add BionicAllocator::memalign
Move the linker allocator into libc
Replace some of linker_allocator's header includes
Add | to make bionic's trace end print match other trace end prints.
Test: took systrace with bionic tag enabled
Change-Id: Ieabb139dd224aa8045be914f21c0432d42a93755
This is used to prevent the additional indirection even after heap
profiling has finished, preventing any performance impact on processes
that are not currently being profiled.
Test: m
Test: flash sailfish
Test: try tearing down & re-enabling hooks
Bug: 120186127
Change-Id: Idc5988111a47870d2c093fd6a017b47e65f5616b
Initialize a thread's DTV to an empty zeroed DTV. Allocate the DTV and
any ELF module's TLS segment on-demand in __tls_get_addr. Use a generation
counter, incremented in the linker, to signal when threads should
update/reallocate their DTV objects.
A generation count of 0 always indicates the constant zero DTV.
Once a DTV is allocated, it isn't freed until the thread exits, because
a signal handler could interrupt the fast path of __tls_get_addr between
accessing the DTV slot and reading a field of the DTV. Bionic keeps a
linked list of DTV objects so it can free them at thread-exit.
Dynamic TLS memory is allocated using a BionicAllocator instance in
libc_shared_globals. For async-signal safety, access to the
linker/libc-shared state is protected by first blocking signals, then by
acquiring the reader-writer lock, TlsModules::rwlock. A write lock is
needed to allocate or free memory.
In pthread_exit, unconditionally block signals before freeing dynamic
TLS memory or freeing the shadow call stack.
ndk_cruft.cpp: Avoid including pthread_internal.h inside an extern "C".
(The header now includes a C++ template that doesn't compile inside
extern "C".)
Bug: http://b/78026329
Bug: http://b/123094171
Test: bionic unit tests
Change-Id: I3c9b12921c9e68b33dcc1d1dd276bff364eff5d7
A static executable is almost entirely statically relocated by the
linker, with the exception of IRELATIVE relocations, which must be
resolved by libc by enumerating the relocations using the special
linker-defined symbols __rela?_iplt_{start,end}. This patch implements
ifunc support by enumerating the relocations in this way.
Bug: 112482891
Test: /data/nativetest{,64}/bionic-unit-tests-static/bionic-unit-tests-static on walleye_hwasan-userdebug
Change-Id: Ia5522a190da0b86e095b141d5d4e68dd7dd4b695
Bionic needs this functionality to allocate a TLS segment with greater
than 16-byte alignment. For simplicity, this allocator only supports up
to one page of alignment.
The memory layout changes slightly when allocating an object of exactly
PAGE_SIZE alignment. Instead of allocating the page_info header at the
start of the page containing the pointer, it is allocated at the start
of the preceding page.
Bug: http://b/78026329
Test: linker-unit-tests{32,64}
Change-Id: I1c8d1cd7ca72d113bced5ee15ba8d831426b0081
Rename LinkerMemoryAllocator -> BionicAllocator
Rename LinkerSmallObjectAllocator -> BionicSmallObjectAllocator
libc and the linker need to share an instance of the allocator for
allocating and freeing dynamic ELF TLS memory (DTVs and segments). The
linker also continues to use this allocator.
Bug: http://b/78026329
Test: /data/nativetest/bionic-unit-tests-static
Test: /data/nativetest64/bionic-unit-tests-static
Test: /data/nativetest/linker-unit-tests/linker-unit-tests32
Test: /data/nativetest64/linker-unit-tests/linker-unit-tests64
Change-Id: I2da037006ddf8041a75f3eba2071a8fcdcc223ce
If a signal handler is blocking all of their signals, we should
probably respect that and not silently unblock bionic's reserved
signals for them. Otherwise, user code can deadlock, run out of stack,
etc. through no fault of their own, if one of the reserved signals
comes in while they've pivoted onto their signal stack.
Bug: http://b/122939726
Test: treehugger
Change-Id: I6425a3e7413edc16157b35dffe632e1ab1d76618
On user builds, heapprofd should only be allowed to profile apps that
are either debuggable, or profileable (according to the manifest). This
change exposes extra zygote-specific knowledge to bionic, and makes the
dedicated signal handler check for the special case of being in a zygote child.
With this & the corresponding framework change, we should now be
handling the 4 combinations of:
{java, native} x {profile_at_runtime, profile_at_startup}.
See internal go/heapprofd-java-trigger for further context.
Test: on-device unit tests (shared & static) on blueline-userdebug.
Test: flashed blueline-userdebug, confirmed that java profiling activates from startup and at runtime.
Bug: 120409382
Change-Id: Ic251afeca4324dc650ac1d4f46976b526eae692a
(cherry picked from commit 998792e2b6)
Merged-In: Ic251afeca4324dc650ac1d4f46976b526eae692a
This relocation is used for static TLS's initial-exec (IE) accesses.
A TLS symbol's value is its offset from the start of the ELF module's
TLS segment. It doesn't make sense to add the load_bias to this value,
so skip the call to soinfo::resolve_symbol_address.
Allow TLS relocations to refer to an unresolved weak symbol. In that case,
sym will be non-zero, but lsi will be nullptr. The dynamic linker resolves
the TPREL relocation to 0, making &missing_weak_symbol equal the thread
pointer.
Recognize Gold-style relocations to STB_LOCAL TLS symbols/sections and
issue an error.
Remove the "case R_AARCH64_TLS_TPREL64", because the R_GENERIC_TLS_TPREL
case handles it.
Remove the no-op R_AARCH64_TLSDESC handler. It's better to issue an error.
dlopen_library_with_ELF_TLS now fails with a consistent error about an
unimplemented dynamic TLS relocation.
Bug: http://b/78026329
Test: bionic unit tests (elftls tests are added in a later CL)
Change-Id: Ia08e1b5c8098117e12143d3b4ebb4dfaa5ca46ec
If the alignment of a TLS segment in a shared object is invalid, return
an error through dlerror() rather than aborting the process.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I60e589ddd8ca897f485d55af089f08bd3ff5b1fa
This implementation simply iterates over each static TLS module and
copies its initialization image into a new thread's static TLS block.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: Ib7edb665271a07010bc68e306feb5df422f2f9e6
Replace reserve_tcb with reserve_exe_segment_and_tcb, which lays out both
the TCB and the executable's TLS segment, accounting for the difference in
layout between variant 1 and variant 2 targets.
The function isn't actually called with a non-null TlsSegment* yet.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: Ibd6238577423a7d0451f36da7e64912046959796
* changes:
Add a __bionic_get_tls_segment function
Factor out ScopedRWLock into its own header
Build the linker with -D_USING_LIBCXX
Provide a stub aeabi.read_tp on other archs
Remove TLS_SLOT_TSAN(8)
The function searches for a TLS segment in a ElfXX_Phdr table.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I221b13420d1a2da33fc2174b7dd256589f6ecfdb
For ELF TLS "local-exec" accesses, the static linker assumes that an
executable's TLS segment is located at a statically-known offset from the
thread pointer (i.e. "variant 1" for ARM and "variant 2" for x86).
Because these layouts are incompatible, Bionic generally needs to allocate
its TLS slots differently between different architectures.
To allow per-architecture TLS slots:
- Replace the TLS_SLOT_xxx enumerators with macros. New ARM slots are
generally negative, while new x86 slots are generally positive.
- Define a bionic_tcb struct that provides two things:
- a void* raw_slots_storage[BIONIC_TLS_SLOTS] field
- an inline accessor function: void*& tls_slot(size_t tpindex);
For ELF TLS, it's necessary to allocate a temporary TCB (i.e. TLS slots),
because the runtime linker doesn't know how large the static TLS area is
until after it has loaded all of the initial solibs.
To accommodate Golang, it's necessary to allocate the pthread keys at a
fixed, small, positive offset from the thread pointer.
This CL moves the pthread keys into bionic_tls, then allocates a single
mapping per thread that looks like so:
- stack guard
- stack [omitted for main thread and with pthread_attr_setstack]
- static TLS:
- bionic_tcb [exec TLS will either precede or succeed the TCB]
- bionic_tls [prefixed by the pthread keys]
- [solib TLS segments will be placed here]
- guard page
As before, if the new mapping includes a stack, the pthread_internal_t
is allocated on it.
At startup, Bionic allocates a temporary bionic_tcb object on the stack,
then allocates a temporary bionic_tls object using mmap. This mmap is
delayed because the linker can't currently call async_safe_fatal() before
relocating itself.
Later, Bionic allocates a stack-less thread mapping for the main thread,
and copies slots from the temporary TCB to the new TCB.
(See *::copy_from_bootstrap methods.)
Bug: http://b/78026329
Test: bionic unit tests
Test: verify that a Golang app still works
Test: verify that a Golang app crashes if bionic_{tls,tcb} are swapped
Merged-In: I6543063752f4ec8ef6dc9c7f2a06ce2a18fc5af3
Change-Id: I6543063752f4ec8ef6dc9c7f2a06ce2a18fc5af3
(cherry picked from commit 1e660b70da)
This change makes it easier to move the location of the pthread keys
(e.g. into the bionic_tls struct).
Bug: http://b/78026329
Test: bionic unit tests
Test: disassembly of libc.so doesn't change
Merged-In: Ib75d9dab8726de96856af91ec3daa2c5cdbc2178
Change-Id: Ib75d9dab8726de96856af91ec3daa2c5cdbc2178
(cherry picked from commit ecad24fad9)
Track movement of ICU .dat file into the runtime module
This reverts commit b9e7b699a2.
This is a reapply of commit 68c6bd8b43
Bug: 120853401
Bug: 119293618
Test: build / boot
Change-Id: I69e0dde2756da64ac0b17f1726145dccacf5961f
PR_SET_VMA takes mmap_sem, which can cause contention and reduce
performance any time many threads are created at the same time,
like app startup.
Test: camera launch performance
Bug: 122471935
Change-Id: If7fa7ad99654c01d503f694976fd92bfd30d2afd
Having a constexpr constructor should guarantee that the static
`globals` variable in __libc_shared_globals is initialized statically
(as opposed to dynamically), which is important because
__libc_shared_globals is called very early (before the linker has
relocated itself). With the constructor, though, the fields can safely
have in-line default initializers.
Bug: none
Test: bionic unit tests
Change-Id: Icde821557369625734a4d85d7ff55428bad5c247
We could cause illegal memory access due to not checking the scanddir
return value.
Test: run linux-bionic dex2oat to build boot.oat
Bug: 119332362
Change-Id: Ic5824e0373b9b99d8f892b4fcf22e742c6f792da
* Add explicit to conversion constructors/operators
Bug: 28341362
Test: make with WITH_TIDY=1 DEFAULT_GLOBAL_TIDY_CHECKS=-*,google-explicit-constructor
Change-Id: Id1ad0327c1b8c6f094bcbb3ae599bc1f716b3f2f
This change is intended to allow native-bridge to use independent
TLS memory for host and guest environments, while still sharing a
thread-local errno between the two.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I838cd321e159add60760bc12a8aa7e9ddc960c33
Merged-In: I838cd321e159add60760bc12a8aa7e9ddc960c33
(cherry picked from commit a9c7c55462)
Instead of passing the address of a KernelArgumentBlock to libc.so for
initialization, use __loader_shared_globals() to initialize globals.
Most of the work happened in the previous CLs. This CL switches a few
KernelArgumentBlock::getauxval calls to [__bionic_]getauxval and stops
routing the KernelArgumentBlock address through the libc init functions.
Bug: none
Test: bionic unit tests
Change-Id: I96c7b02c21d55c454558b7a5a9243c682782f2dd
Merged-In: I96c7b02c21d55c454558b7a5a9243c682782f2dd
(cherry picked from commit 746ad15912)
Make getauxval() work in .preinit_array. It still won't be usable for
ifuncs unless we can guarantee that the __loader_shared_globals relocation
is resolved before the ifunc calls [__bionic_]getauxval.
Define __bionic_getauxval for use in replacing calls to
KernelArgumentBlock::getauxval, which doesn't (and sometimes isn't allowed
to) access TLS variables like errno.
Bug: http://b/25751302
Test: bionic unit tests
Change-Id: I461feeaed7f43cfa2a2b6c34147194f0df82b516
Merged-In: I461feeaed7f43cfa2a2b6c34147194f0df82b516
(cherry picked from commit bdab4a2b97)
Split __libc_init_main_thread into __libc_init_main_thread_early and
__libc_init_main_thread_late. The early function is called very early in
the startup of the dynamic linker and static executables. It initializes
the global auxv pointer and enough TLS memory to do system calls, access
errno, and run -fstack-protector code (but with a zero cookie because the
code for generating a cookie is complex).
After the linker is relocated, __libc_init_main_thread_late finishes
thread initialization.
Bug: none
Test: bionic unit tests
Change-Id: I6fcd8d7587a380f8bd649c817b40a3a6cc1d2ee0
Merged-In: I6fcd8d7587a380f8bd649c817b40a3a6cc1d2ee0
(cherry picked from commit 39bc44bb0e)
Because we also want to profile Java applications, which have longer
names, the character limit of comm is a problem. To avoid complexity, it
is preferable to apply the same logic for finding running processes
(which includes Java apps), and determining whether to profile a process
from startup.
Test: m
Test: flash sailfish
Test: setprop heapprofd.enable 1
setprop heapprofd.enable.ls 1
ls
/system/bin/ls
/system/bin/ls /
Bug: 120175590
Change-Id: Id0859d4a333efcb05883e611ea6a31a51468f82c
* changes:
Use shared globals to init __progname + environ
Move the abort message to libc_shared_globals
Expose libc_shared_globals to libc.so with symbol
Initialize the __progname and environ global variables using
libc_shared_globals rather than KernelArgumentBlock.
Also: suppose the linker is invoked on an executable:
linker prog [args...]
The first argument passed to main() and constructor functions is "prog"
rather than "linker". For consistency, this CL changes the BSD
__progname global from "linker" to "prog".
Bug: none
Test: bionic unit tests
Change-Id: I376d76953c9436706dbc53911ef6585c1acc1c31
__libc_shared_globals() is available in dynamic modules as soon as
relocation has finished (i.e. after ifuncs run). Before ifuncs have run,
the android_set_abort_message() function already doesn't work because it
calls public APIs via the PLT. (If this matters, we can use a static
bool variable to enable android_set_abort_message after libc
initialization).
__libc_shared_globals() is hidden, so it's available in the linker
immediately (i.e. before relocation). TLS memory (e.g. errno) currently
isn't accessible until after relocation, but a later patch fixes that.
Bug: none
Test: bionic unit tests
Change-Id: Ied4433758ed2da9ee404c6158e319cf502d05a53
Previously, the address of the global variable was communicated from the
dynamic linker to libc.so using a field of KernelArgumentBlock, which is
communicated using the TLS_SLOT_BIONIC_PREINIT slot.
As long as this function isn't called during relocations (i.e. while
executing an ifunc), it always return a non-NULL value. If it's called
before its PLT entry is relocated, I expect a crash.
I removed the __libc_init_shared_globals function. It's currently empty,
and I don't think there's one point in libc's initialization where
shared globals should be initialized.
Bug: http://b/25751302
Test: bionic unit tests
Change-Id: I614d25e7ef5e0d2ccc40d5c821dee10f1ec61c2e
Other minor changes:
* document assignment that relies on _Atomic assignments to use
atomic_store.
* consistently use atomic_store when assigning to atomics.
* remove incorrect comment.
Test: m
Test: flash & boot sailfish
Change-Id: I4789c08f7ac28a2de8d6925d03af354514bfd9d7
__sanitize_environment_variables is only called when getauxval(AT_SECURE)
is true.
Instead of scanning __libc_auxv, reuse getauxval. If the entry is missing,
getauxval will set errno to ENOENT.
Reduce the number of times that __libc_sysinfo and __libc_auxv are
initialized. (Previously, __libc_sysinfo was initialized 3 times for the
linker's copy). The two variables are initialized in these places:
- __libc_init_main_thread for libc.a (including the linker copy)
- __libc_preinit_impl for libc.so
- __linker_init: the linker's copy of __libc_sysinfo is still initialized
twice, because __libc_init_main_thread runs after relocation. A later
CL consolidates the linker's two initializations.
Bug: none
Test: bionic unit tests
Change-Id: I196f4c9011b0d803ee85c07afb415fcb146f4d65
remove android_open_proxy and use dns_open_proxy instead of it.
dns_open_proxy is in libnetd_client and
it does the same thing as android_open_proxy except return value.
It returns fd directly now.
Test: build, dns works fine
Change-Id: I984743fb50b23eeb9a7d24e9fc347832acfe2afe
This lets us do two things:
1) Make setjmp and longjmp compatible with shadow call stack.
To avoid leaking the shadow call stack address into memory, only the
lower log2(SCS_SIZE) bits of x18 are stored to jmp_buf. This requires
allocating an additional guard page so that we're guaranteed to be
able to allocate a sufficiently aligned SCS.
2) SCS overflow detection. Overflows now result in a SIGSEGV instead
of corrupting the allocation that comes after it.
Change-Id: I04d6634f96162bf625684672a87fba8b402b7fd1
Test: bionic-unit-tests
Also move this and android_get_device_api_level into <android/api-level.h>
so that they're always available.
This involves cleaning up <sys/cdefs.h> slightly.
Bug: N/A
Test: builds
Change-Id: I25435c55f3549cd0d827a7581bee75ea8228028b
