This library is used by a number of different libraries in the system.
Make it easy for platform libraries to use this library and create
an actual exported include file.
Change the names of the functions to reflect the new name of the library.
Run clang_format on the async_safe_log.cpp file since the formatting is
all over the place.
Bug: 31919199
Test: Compiled for angler/bullhead, and booted.
Test: Ran bionic unit tests.
Test: Ran the malloc debug tests.
Change-Id: I8071bf690c17b0ea3bc8dc5749cdd5b6ad58478a
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.
Add ANDROID_DNS_MODE to the list of unsafe variables.
Similar to RESOLV_HOST_CONF and RES_OPTIONS (which are already
blacklisted), this variable controls how name resolution requests are
handled. Allowing ANDROID_DNS_MODE to be set across a security
boundary could induce resolution failures or otherwise impact
name resolution.
Remove BIONIC_DNSCACHE. This does not appear to be used, and setting
this variable across a security boundary could cause name resolution
problems.
Test: Android compiles and runs with no obvious problems.
Change-Id: I835a7b42d6afbc9c67866594c7951cfd9b355d81
Used by CFI, so broke cfi_test#early_init@x86, but I've added a specific
test for this (and a similar test for getauxval from preinit, which this
patch does not fix).
Bug: http://b/35885875
Test: ran tests
Change-Id: I43885bedfb88c0a26b4474bd3c27a87dec7bbc97
Another release, another attempt to fix this bug.
This change affects pthread_detach, pthread_getcpuclockid,
pthread_getschedparam/pthread_setschedparam, pthread_join, and pthread_kill:
instead of returning ESRCH when passed an invalid pthread_t, they'll now SEGV.
Note that this doesn't change behavior as much as you might think: the old
lookup only held the global thread list lock for the duration of the lookup,
so there was still a race between that and the dereference in the caller,
given that callers actually need the tid to pass to some syscall or other,
and sometimes update fields in the pthread_internal_t struct too.
We can't check thread->tid against 0 to see whether a pthread_t is still
valid because a dead thread gets its thread struct unmapped along with its
stack, so the dereference isn't safe.
Taking the affected functions one by one:
* pthread_getcpuclockid and pthread_getschedparam/pthread_setschedparam
should be fine. Unsafe calls to those seem highly unlikely.
* Unsafe pthread_detach callers probably want to switch to
pthread_attr_setdetachstate instead, or using pthread_detach(pthread_self())
from the new thread's start routine rather than doing the detach in the
parent.
* pthread_join calls should be safe anyway, because a joinable thread won't
actually exit and unmap until it's joined. If you're joining an
unjoinable thread, the fix is to stop marking it detached. If you're
joining an already-joined thread, you need to rethink your design.
* Unsafe pthread_kill calls aren't portably fixable. (And are obviously
inherently non-portable as-is.) The best alternative on Android is to
use pthread_gettid_np at some point that you know the thread to be alive,
and then call kill/tgkill directly. That's still not completely safe
because if you're too late, the tid may have been reused, but then your
code is inherently unsafe anyway.
If we find too much code is still broken, we can come back and disable
the global thread list lookups for anything targeting >= O and then have
another go at really removing this in P...
Bug: http://b/19636317
Test: N6P boots, bionic tests pass
Change-Id: Ia92641212f509344b99ee2a9bfab5383147fcba6
The linker calls to __libc_fatal resulted in tombstones
with missing abort message. This commit fixes it by
initializing __abort_message_ptr for the linker's copy
of libc.
Bug: http://b/31095185
Change-Id: I883d654d7fd0ef309c80f8021202b6bfd5d5cea5
Before, dynamic executables would initialize the global stack protector
twice, once for the linker, and once for the executable. This worked
because the result was the same for both initializations, because it
used getauxval(AT_RANDOM), which won't be the case once arc4random gets
used for it.
Bug: http://b/29622562
Change-Id: I7718b1ba8ee8fac7127ab2360cb1088e510fef5c
Test: ran the stack protector tests on angler (32/64bit, static/dynamic)
Previously, arc4random would register a fork-detecting pthread_atfork
handler to not have to call getpid() after a fork. pthread_atfork uses
pthread_mutex_lock, which requires the current thread to be initialized,
preventing the use of arc4random for initializing the global stack guard,
which needs to happen before the main thread has been initialized.
Extract the arc4random fork-detection flag and use the existing
arc4random fork handler to set it.
Bug: http://b/29622562
Change-Id: I98c9329fa0e489c3f78cad52747eaaf2f5226b80
Although there is a test pthread.pthread_mutex_owner_tid_limit
to check pid_max, but bionic-unit-tests hangs before reaching
that test. So abort at libc initialization if not able to reach
the test when running bionic-unit-tests32. It is more friendly
for debugging.
Bug: 24016357
Change-Id: Ia70c2e36fd8a3a040d41ea5722c7b48a6134e102
This patch uses __kernel_vsyscall instead of "int 0x80"
as the syscall entry point. AT_SYSINFO points to
an adapter to mask the arch specific difference and gives a
performance boost on i386 architecture.
Change-ID: Ib340c604d02c6c25714a95793737e3cfdc3fc5d7
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
The major components of the rewrite:
- Completely remove the qemu shared library code. Nobody was using it
and it appears to have broken at some point.
- Adds the ability to enable/disable different options independently.
- Adds a new option that can enable the backtrace on alloc/free when
a process gets a specific signal.
- Adds a new way to enable malloc debug. If a special property is
set, and the process has an environment variable set, then debug
malloc will be enabled. This allows something that might be
a derivative of app_process to be started with an environment variable
being enabled.
- get_malloc_leak_info() used to return one element for each pointer that
had the exact same backtrace. The new version returns information for
every one of the pointers with same backtrace. It turns out ddms already
automatically coalesces these, so the old method simply hid the fact
that there where multiple pointers with the same amount of backtrace.
- Moved all of the malloc debug specific code into the library.
Nothing related to the malloc debug data structures remains in libc.
- Removed the calls to the debug malloc cleanup routine. Instead, I
added an atexit call with the debug malloc cleanup routine. This gets
around most problems related to the timing of doing the cleanup.
The new properties and environment variables:
libc.debug.malloc.options
Set by option name (such as "backtrace"). Setting this to a bad value
will cause a usage statement to be printed to the log.
libc.debug.malloc.program
Same as before. If this is set, then only the program named will
be launched with malloc debug enabled. This is not a complete match,
but if any part of the property is in the program name, malloc debug is
enabled.
libc.debug.malloc.env_enabled
If set, then malloc debug is only enabled if the running process has the
environment variable LIBC_DEBUG_MALLOC_ENABLE set.
Bug: 19145921
Change-Id: I7b0e58cc85cc6d4118173fe1f8627a391b64c0d7
Exactly which functions get a stack protector is up to the compiler, so
let's separate the code that sets up the environment stack protection
requires and explicitly build it with -fno-stack-protector.
Bug: http://b/26276517
Change-Id: I8719e23ead1f1e81715c32c1335da868f68369b5
We need to ensure %gs:20 is set up early enough for -fstack-protector-strong
on x86, and that __set_tls doesn't get stack protector checks because it's a
prerequisite for them. x86 devices/emulators won't boot without this.
Bug: http://b/26073874
Change-Id: Icf0d34294648cc0c8cb406a3617befe0d45c525a
This reverts commit c8bae05f3f.
We were breaking init (ueventd) because we initialize system properties
before we initialize stdio. The new system property implementation uses
stdio to read from /property_contexts, so we end up touching stdio data
structures before they've been initialized.
This second attempt takes things further by removing the stdio initialization
function altogether. The data structures for stdin/stdout/stderr can be
statically initialized as data, and -- since we already had to give the
atexit implementation a backdoor for stdio -- we can just admit that we
need to clean up stdio, and that we always do so last.
This patch also removes the 17 statically pre-allocated file structures,
so the first fopen will now allocate a block of 10 (the usual overflow
behavior). I did this just to make my life simpler, but it's not actually
necessary to remove it if we want it back.
Change-Id: I936b2eb5e88e4ebaf5516121872b71fc88e5609c
This reverts commit 4371961e00.
This broke booting; ueventd crashes with a null pointer dereference
somewhere in __sfp (but the kernel doesn't unwind, so I don't know
what was calling __sfp).
Change-Id: I65375fdfdf1d339a06558b4057b580cacd6324e2
Previously we call __sinit() lazily. But it is likely to cause data
races like in https://android-review.googlesource.com/#/c/183237/. So
we prefer to call __sinit() explicitly at libc initialization.
Bug: 25392375
Change-Id: I181ea7a4b2e4c7350b45f2e6c86886ea023e80b8
If tsan is used, the following callchain can happen:
__libc_preinit() -> __libc_init_globals() ->
__libc_init_vdso() -> strcmp() -> __tsan_init()
-> sysconf(_SC_PAGE_SIZE) -> getauxval().
But __libc_auxv is initialized in __libc_init_common(),
after __libc_init_globals(). One simple way to fix
this is to initialize __libc_auxv at __libc_init_globals().
Bug: 25392375
Change-Id: I3893b1f567d5f3b7a8c881c0c1b8234b06b7751b
The current comment implies that we only strip sensitive
environment variables on executing a setuid program. This is
true but incomplete. The AT_SECURE flag is set whenever a
security transition occurs, such as executing a setuid program,
SELinux security transition, executing a file with file capabilities,
etc...
Fixup the comments.
Change-Id: I30a73992adfde14d6e5f642b3a1ead2ee56726be
Reuse the top bits of _JB_SIGFLAG field previously used to store a
boolean to store a cookie that's validated by [sig]longjmp to make it
harder to use as a ROP gadget. Additionally, encrypt saved registers
with the cookie so that an attacker can't modify a register's value to
a specific value without knowing the cookie.
Bug: http://b/23942752
Change-Id: Id0eb8d06916e89d5d776bfcaa9458f8826717ba3
1. Personality parameter should be unsigned int (not long)
2. Do not reset bits outside of PER_MASK when setting
personality value.
3. Set personality for static executables.
Bug: http://b/21900686
Change-Id: I4c7e34079cbd59b818ce221eed325c05b9bb2303
(cherry picked from commit f643eb38c3)
As glibc/netbsd don't protect access to thread struct members by a global
lock, we don't want to do it either. This change reduces the
responsibility of g_thread_list_lock to only protect g_thread_list.
Bug: 19636317
Change-Id: I897890710653dac165d8fa4452c7ecf74abdbf2b
Make this change because I think it is more reasonable to check stack info
in pthread_getattr_np. I believe pthread_attr_t is not tied with any thread,
and can't have a flag saying who using it is the main thread.
This change also helps refactor of g_thread_list_lock.
Bug: 19636317
Change-Id: Iedbb85a391ac3e1849dd036d01445dac4bc63db9
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Change-Id: I1d4dbffe7bc7bda1d353c3a295dbf68d29f63158
In practice, with this implementation we never need to make a system call.
We get the main thread's tid (which is the same as our pid) back from
the set_tid_address system call we have to make during initialization.
A new pthread will have the same pid as its parent, and a fork child's
main (and only) thread will have a pid equal to its tid, which we get for
free from the kernel before clone returns.
The only time we'd actually have to make a getpid system call now is if
we take a signal during fork and the signal handler calls getpid. (That,
or we call getpid in the dynamic linker while it's still dealing with its
own relocations and hasn't even set up the main thread yet.)
Bug: 15387103
Change-Id: I6d4718ed0a5c912fc75b5f738c49a023dbed5189
Let the kernel keep pthread_internal_t::tid updated, including
across forks and for the main thread. This then lets us fix
pthread_join to only return after the thread has really exited.
Also fix the thread attributes of the main thread so we don't
unmap the main thread's stack (which is really owned by the
dynamic linker and contains things like environment variables),
which fixes crashes when joining with an exited main thread
and also fixes problems reported publicly with accessing environment
variables after the main thread exits (for which I've added a new
unit test).
In passing I also fixed a bug where if the clone(2) inside
pthread_create(3) fails, we'd unmap the child's stack and TLS (which
contains the mutex) and then try to unlock the mutex. Boom! It wasn't
until after I'd uploaded the fix for this that I came across a new
public bug reporting this exact failure.
Bug: 8206355
Bug: 11693195
Bug: https://code.google.com/p/android/issues/detail?id=57421
Bug: https://code.google.com/p/android/issues/detail?id=62392
Change-Id: I2af9cf6e8ae510a67256ad93cad891794ed0580b
The x86_64 build was failing because clone.S had a call to __thread_entry which
was being added to a different intermediate .a on the way to making libc.so,
and the linker couldn't guarantee statically that such a relocation would be
possible.
ld: error: out/target/product/generic_x86_64/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(clone.o): requires dynamic R_X86_64_PC32 reloc against '__thread_entry' which may overflow at runtime; recompile with -fPIC
This patch addresses that by ensuring that the caller and callee end up in the
same intermediate .a. While I'm here, I've tried to clean up some of the mess
that led to this situation too. In particular, this removes libc/private/ from
the default include path (except for the DNS code), and splits out the DNS
code into its own library (since it's a weird special case of upstream NetBSD
code that's diverged so heavily it's unlikely ever to get back in sync).
There's more cleanup of the DNS situation possible, but this is definitely a
step in the right direction, and it's more than enough to get x86_64 building
cleanly.
Change-Id: I00425a7245b7a2573df16cc38798187d0729e7c4
__page_shift and __page_size were accidentally declared in unistd.h with
C linkage - their implementation needs to use the same linkage.
Going forward, though, let's stop the inlining madness and let's kill
the non-standard __getpageshift(). This patch takes getpagesize(3) out
of line and removes __getpageshift but fixes __page_shift and __page_size
for backwards binary compatibility.
Change-Id: I35ed66a08989ced1db422eb03e4d154a5d6b5bda
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
