snprintf to a buffer of length PATH_MAX consumes about 7kB of stack.
Bug: http://b/35858739
Test: bionic-unit-tests --gtest_filter="*big_enough*"
Change-Id: I34a7f42c1fd2582ca0d0a9b7e7a5290bc1cc19b1
This changes system_properties' initialize_properties to prefer
loading property_contexts from /system/etc/selinux &
/vendor/etc/selinux, while falling back to the pre-existing behavior
of loading from /.
Test: Device with *_property_contexts in / boots up fine, no denials
to do with properties, getprop -Z lists correct labels.
Test: Device with *_property_contexts in /system & /vendor, but not
in /, boots up fine, no denials to do with properties,
getprop -Z lists correct labels.
Test: Device with *_property_contexts in /system & vendor and with
empty *_property_contexts in / boots up fine, no denials to do
with properties, getprop -Z lists correct labels.
Bug: 36002573
Change-Id: I15174acdf89ee8f5a96acf1e38a54d4214df51ef
__pthread_internal_free doesn't happen on threads that are detached,
causing the bionic TLS allocation (and guard pages) to be leaked.
Fix the leak, and name the allocations to make things apparent if this
ever happens again.
Bug: http://b/36045112
Test: manually ran a program that detached empty threads
Change-Id: Id1c7852b7384474244f7bf5a0f7da54ff962e0a1
Apparently that "backdoor" is no longer needed - the proper way is
to reinitialize properties:
https://android-review.googlesource.com/#/c/181794/24/tests/system_properties_test.cpp
Also removes mentions of libnativehelper test (it no longer uses
__system_property_area__) and removes useless "extern" declaration
(actual use was removed long ago).
Test: refactoring CL, existsing tests still pass
BUG=21852512
BUG=34114501
Change-Id: I2223cab2fcb671ea180ad4470a7aba5c9cd20bd8
__system_property_set sometimes produces broken_pipe error
when trying to write a property.
This change improves error messages and uses writev() instead
of sequence of send() calls.
Bug: http://b/35381074
Test: bionic-unit-tests --gtest_filter=prop*
Change-Id: I7a5b169c015db4e6b720370e58662de8206d1086
This seemed to be the only place in bionic where a fence on a
performance-critical path could be easily replaced by a stronger
load/store order constraint. Do so.
On x86 this should generate the same code either way. Based on
microbenchmarks of the relevant ARM instructions, this is currently
performance-neutral in this kind of context. But in the future, the
newly generated acquire loads should give us a performance benefit.
Test: Booted AOSP
Change-Id: I7823e11d6ae4fd58e0425244c293262e2320fd81
Thread local buffers were using pthread_setspecific for storage with
lazy initialization. pthread_setspecific shares TLS slots between the
linker and libc.so, so thread local buffers being initialized in a
different order between libc.so and the linker meant that bad things
would happen (manifesting as snprintf not working because the
locale was mangled)
Bug: http://b/20464031
Test: /data/nativetest64/bionic-unit-tests/bionic-unit-tests
everything passes
Test: /data/nativetest/bionic-unit-tests/bionic-unit-tests
thread_local tests are failing both before and after (KUSER_HELPERS?)
Test: /data/nativetest64/bionic-unit-tests-static/bionic-unit-tests-static
no additional failures
Change-Id: I9f445a77c6e86979f3fa49c4a5feecf6ec2b0c3f
So far this is the only issue we've hit in vendor code, and we've hit
it several times already. Rather than try to fix bullhead (the current
problem), let's just admit that the special case of 0 is a lot less
worrying.
Also fix the test expectations to correspond to the new abort message.
Bug: http://b/35455349 (crashes on 0)
Bug: http://b/35622944 (tests)
Test: ran tests
Change-Id: Iec57011fa699a954ebeaec151db2193e36d1ef35
The comment isn't helpful as-is. Provide some clarifying information.
Test: code compiles. No functional changes.
Change-Id: I5267e0bc68857fdc8a4b3384a2a1b0d37693ee6e
Another release, another attempt to remove the global thread list.
But this time, let's admit that it's not going away. We can switch to using
a read/write lock for the global thread list, and to aborting rather than
quietly returning ESRCH if we're given an invalid pthread_t.
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, if you're
targeting O or above, they'll abort with the message "attempt to use
invalid pthread_t".
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.
(This patch replaces such users with calls to pthread_gettid_np, which
at least makes the TOCTOU window smaller.)
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.
Bug: http://b/19636317
Test: ran tests
Change-Id: I0372c4428e8a7f1c3af5c9334f5d9c25f2c73f21
In order to implement android::base::WaitForProperty well, we need a way to
wait not for *any* property to change (__system_property_wait_any), but to
specifically wait for the property represented by a given `prop_info` to
change.
The android::base::WaitForProperty implementation, like attempts to cache
system properties in the past, also needs a way to keep serials and values
in sync, but the existing functions don't provide a cheap way to get a
consistent snapshot. Change the __system_property_read_callback callback's
type to include the serial corresponding to the given value.
Add a test, slightly clean up some of the existing tests (and name them to
include the names of the functions they're testing, in our usual style).
Bug: http://b/35201172
Test: ran tests
Change-Id: Ibc8ebe2e88eef1e333a1bd3dd7f68135f1ba7fb5
This patch adds clang-style FORTIFY to Bionic. For more information on
FORTIFY, please see https://goo.gl/8HS2dW . This implementation works
for versions of clang that don't support diagnose_if, so please see the
"without diagnose_if" sections. We plan to swap to a diagnose_if-based
FORTIFY later this year (since it doesn't really add any features; it
just simplifies the implementation a lot, and it gives us much prettier
diagnostics)
Bug: 32073964
Test: Builds on angler, bullhead, marlin, sailfish. Bionic CTS tests
pass on Angler and Bullhead.
Change-Id: I607aecbeee81529709b1eee7bef5b0836151eb2b
Since removing the global thread is hard, let's take the different
groups of functions individually.
The existing code was racy anyway, because the thread might still be
on the list but have exited (leaving tid == 0).
Bug: http://b/19636317
Test: ran tests
Change-Id: Icc0986ff124d5f9b8a653edf718c549d1563973b
gerrit still hasn't sent out the mail asking for this in an earlier code
review...
Bug: http://b/33926793
Test: builds and boots.
Change-Id: I080de633e50e47f9a052211d47da96b971b16424
No-one is directly upgrading from pre-K to O...
Also move more implementation details out of the header file.
Bug: http://b/33926793
Test: boots
Change-Id: I7a0936acbb1cea8a3b2cd6797ec53ba7e4a050f3
Bug: 33746484
Bug: 34370523
Test: Successfully boot with original service and property contexts.
Test: Successfully boot with split serivce and property contexts.
Test: Incremental build works on sailfish (reported in b/34370523)
Test: adb sideload works with aosp updater (reported in b/34370523)
Change-Id: Idf24856193032a8bc89ec384a72451e578a9d5ac
Signed-off-by: Sandeep Patil <sspatil@google.com>
Trying to send even 0 bytes to closed socket leads to
broken pipe error. Sometimes property service is just
quick enough and closes the socket between send(valuelen)
and send(value) in the case where valuelen is 0.
Bug: http://b/34670529
Test: adb reboot 20 times and make sure phone service did not fail
Test: run bionic-unit-tests --gtest_filter=prop*
Change-Id: I96f90ca6fe1790614e7efd3015bffed1ef1e9040
This change introduces new __system_property_read_callback
method to use in place of deprecated __system_property_read
__system_property_set() and get() should just work but now
do not have limit on system property names.
Bug: http://b/33926793
Test: boot device, run adb shell propget
Test: boot device with old version of init (protocol v1)
Test: run bionic-unit-tests --gtest_filter=prop*
Change-Id: I619fb5a7e27a272aac30011579665f6160888bc7
These functions are supposed to be used only by the
property service.
__system_property_find_nth is deprecated and no longer part
of NDK. Call to this function will result in abort for apps
targeting Android O.
Bug: http://b/34114501
Test: bionic-unit-tests --gtest_filter=prop*
Change-Id: I9846965bf248e2ddf45cd7b293618245bbd87145
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
Don't allow processes to read the contents of the directory
/dev/__properties__. This is an implementation detail of the properties
system that processes shouldn't be concerned with.
Test: Device boots and no problems reading individual properties.
Test: ls -la /dev/__properties__ fails
Change-Id: I00130fe4529525935654bff91e3cc59253b86e26
To support upcoming disk usage calculation optimizations, this change
creates a new GID for each app that will be used to mark its cached
data. We're allocating these unique GIDs so that we can use
quotactl() to track cached data on a per-app basis.
Test: builds, boots, tests pass
Bug: 27948817
Change-Id: Ic00c39ccedc23d5d43988029e9921679126f8f2d
Some of the function pointer types were wrong, and x86 cares if you
say `int` when you meant `int8_t` (because it feels at liberty to
leave the top bits dirty and ignore them, both sides need to agree
which they're dealing with).
Also slightly improve the wcstoimax and wcstoumax tests, since my
investigation started there.
Bug: http://b/33451822
Test: tests pass on x86, arm, and arm64
Change-Id: I553193962f0cb993666f9f8e415990bba5b669e1
Generate the android_ids array and include into the
build.
Test: The bionic is built and that core AIDs work as
expected with commands like chown, mkdir and init services
and builtins.
Bug: 27999086
Change-Id: Ib575bf85326c91801c5674db475dcb9cf44c00dc
Signed-off-by: William Roberts <william.c.roberts@intel.com>
<sys/limits.h> shouldn't even exist, but leave it in for backwards
compatibility.
Everything that seems legit moves to <limits.h>, though it still seems
like a lot of that ought to come from the compiler instead (there's even
an angry rant in the clang header to that effect).
Unfortunately, we've long exposed [a copy and paste of] the contents
of <float.h> from <limits.h> and <sys/limits.h>. This patch preserves
that for backwards compatibility, but at least switches us over to
using the real <float.h> instead.
Bug: http://b/32776472
Test: builds
Change-Id: I2d5b3b5237b3a0442195e99bb967c076ce484f35
Some PoS internal system can't cope with more than 4 stack frames,
so the fact that our abort(3) implementation takes 4 frames by itself
makes it useless.
Re-reading POSIX, it only says "behaves as if", so the previous
implementation chain wasn't mandatory and we can just go straight to
calling tgkill...
Before:
#00 pc 0000000000069be4 /system/lib64/libc.so (tgkill+8)
#01 pc 0000000000066d50 /system/lib64/libc.so (pthread_kill+64)
#02 pc 0000000000028110 /system/lib64/libc.so (raise+24)
#03 pc 000000000001d4ec /system/lib64/libc.so (abort+52)
After:
#00 pc 0000000000069bc8 /system/lib64/libc.so (tgkill+8)
#01 pc 000000000001d4c8 /system/lib64/libc.so (abort+80)
#02 pc 0000000000001494 /system/xbin/crasher64 (_ZL9do_actionPKc+872)
#03 pc 00000000000010e0 /system/xbin/crasher64 (main+88)
This is less useful on 32-bit ARM because there there's an extra trampoline
from an assembler abort(3) implementation, so you'll still only get one
meaningful stack frame. But every other architecture will now get two!
But wait!
It turns out that the assembler hack isn't needed any more. Here we are
unwinding just fine all the way through the 32-bit ARM crasher:
Before (with direct call to tgkill but still using the assembler):
#00 pc 00049e7c /system/lib/libc.so (tgkill+12)
#01 pc 00019c6f /system/lib/libc.so (__libc_android_abort+50)
#02 pc 000181f8 /system/lib/libc.so (abort+4)
#03 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#04 pc 00017721 /system/lib/libc.so (__libc_init+48)
#05 pc 00000b38 /system/xbin/crasher (_start+96)
After:
#00 pc 00049e6c /system/lib/libc.so (tgkill+12)
#01 pc 00019c5f /system/lib/libc.so (abort+50)
#02 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#03 pc 00017721 /system/lib/libc.so (__libc_init+48)
#04 pc 00000b38 /system/xbin/crasher (_start+96)
(As you can see, the fact that we see __libc_init rather than main was true
with the assembler stub too, so that's not a regression even if it does seem
odd...)
Bug: N/A
Test: ran crasher64
Change-Id: I9dd5b214c495604c8b502c7ec0de3631080d8c29
Let the caller know when libc has an entropy source and arc4random is safe.
This is useful for the callers that want entropy, but don't absolutely need it.
Bug: http://b/27729263
Test: booted angler-userdebug w/ safestack
Change-Id: Iab3050bd19f23518e1676629573eebc656ba1090
Pretty useless, because the POSIX APIs are useless for actually
internationalization, but it lets us put this to bed for good.
Bug: http://b/18492914
Test: bionic tests
Change-Id: I4dd0aff66c44b5547039be3ffea806c865b9014a
By default getrandom() blocks if the entropy pool has not yet been initialized.
This will be an issue when init was first executed in some kernels.
This CL makes a check of getrandom readyness, by adding the GRND_NONBLOCK flag.
In such case, getrandom() does not block returns -1 with errno set to EAGAIN.
Test: on M/S devices
Bug: 33059407
Change-Id: I2a2ba8372a5e1c336852ba2ab77cdaac03c90389
POSIX locale only, as usual.
The GNU YESSTR and NOSTR extensions return the empty string in the C locale,
so I haven't bothered supporting them.
Bug: http://b/1401872
Test: bionic tests
Change-Id: I6846839e4f9f1812344ed5dce0b93f83c0c20eb3
Previously malloc debug can be enabled only using global settings
accessible to the root user only. This CL adds a new option to enable
it using environment variables making it possible to use it with pure
native (shell) applications on production builds (from shell user) and
prepares it for using it from logwrapper on production devices.
Remove the old environment variable and property since they are not
necessary.
Test: Enable malloc debug using environment variable and verify
Test: that it only affects the commands launched from the shell.
Test: Enable malloc debug using the property variable and verify
Test: that it affects all commands.
Test: Run all unit tests in 32 bit and 64 bit.
Change-Id: Iecb75a3471552f619f196ad550c5f41fcd9ce8e5
For some program implementation, the pattern like below, calling
pthread_atfork to register atfork interfaces.
pthread_atfork(&atfork_prepare, &atfork_parent, &atfork_child);
When the program is expected to reopen the shared library's handle
inherited from parent in child process. Maybe, dlclose is called in
atfork_child to release the shared library handle before reopen it.
Then, dlclose will indrectly call _cxa_finalize and finaly call
__unregister_atfork when dso is not NULL.
atfork_child() -> dlclose() -> __on_dlclose()
-> __cxa_finalize() -> __unregister_atfork(dso)
In __unregister_atfork, firstly, it try to hold the g_atfork_list_mutex
lock to operate the g_atfork_list. Due to the registered atfork_child is
executed before resetting g_atfork_list_mutex lock in child, the child
process will be blocked here because of deadlock.
Test: bionic-unit-tests32 --gtest_filter=pthread.pthread_atfork_child_with_dlclose
without the fixing, the test will be timeout.
Change-Id: I35d3001682c836e0955d6d681bc5f9297fad0c7b
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
Signed-off-by: Qiming Shi <qiming.shi@intel.com>
Signed-off-by: Chao Xie <chao.xie@intel.com>
This was previously done only in fork() and pthread_create(), but this left raw
clone() with an invalid cached tid. Since the tid is used for pthread routines,
this led to unstable behavior after clone().
Test: ltp clone01 (see bug for more)
Test: mmma bionic/tests
Test: bionic-unit-tests-static --gtest_filter=*fork*:*clone*
Bug: 32612735
Bug: 32305649
Change-Id: I30eae5a8024b4c5da65476fcadfe14c6db35bb79
The tid is cached in the pthread_internal_t and is properly re-set after fork()
and pthread_create(). But after a plain clone() the value is stale from the
parent.
Test: mmma bionic/tests
Test: bionic-unit-tests-static --gtest_filter=*fork*:*clone*
Test: m checkbuild tests
Test: angler boots
Bug: 32305649
Change-Id: I026d416d1537484cd3e05c8493a35e5ed2acc8ed
"ls -q" (or "adb shell -tt ls") was mangling non-ASCII because mbrtowc
was returning multibyte characters as their individual bytes. This was
because toybox asks for "" rather than "C.UTF-8", and for some reason
we were interpreting that as "C" rather than "C.UTF-8".
Test: bionic tests, ls
Change-Id: Ic60e3b90cd5fe689e5489fad0d5d91062b9594ed
An NLMSG_ERROR packet includes an errno value that we should use. Also report
failures to create a socket immediately, rather than falling through to the
send and reporting EBADF.
Bug: http://b/32145516
Bug: http://b/31038971
Test: bionic ifaddr tests on ryu (with broken kernel) and flounder
Change-Id: I84c480c5b75077eb90d40426a9d66d7bffbd3d51
/dev/stderr is a symlink to /proc/self/fd/2, so this only has different
behavior when we're out of file descriptors, or when STDERR_FILENO is in
a different state (it's not at the end, it's not writable, etc.).
Test: mma
Change-Id: Ie99688d810218eca8482ff060373e88c4e001824
libc++ needs these now. Add shims to match the others.
Test: make checkbuild tests
Bug: http://b/31639993
Change-Id: Ifec6c32099145d8d3d1a5639a4809e5e9f553c33
Mips defines CONFIG_ARCH_WANT_IPC_PARSE_VERSION for both 32 and 64-bit.
See arch/mips/Kconfig. Other supported arches do it for 32-bit only.
This translates in having to pass IPC_64 flag for mips32 and mips64.
We use __mips__ to pass the flag, which is also defined for both 32 and
64-bit.
Change fixes bionic smoke tests (sys_msg, sys_sem, sys_shm) for mips64.
Test: bionic-unit-tests --gtest_filter="sys_*.smoke"
Change-Id: I918e4ffafd2002bb3e62ee252406746778100031
The parsefloat routines -- which let us pass NaNs and infinities on to
strto(f|d|ld) -- come from NetBSD.
Also fix LP64's strtold to return a NaN, and fix all the architectures
to return quiet NaNs.
Also fix wcstof/wcstod/wcstold to use parsefloat so they support hex
floats.
Lots of new tests.
Bug: http://b/31101647
Change-Id: Id7d46ac2d8acb8770b5e8c445e87cfabfde6f111
The GCE breakage caused by 78a52f19bb was
due to TLS_SLOT_SELF being uninitialized before the use of errno by
syscall. Separate stack guard initialization from TLS initialization so
that stack guard initialization can make syscalls.
Bug: http://b/29622562
Bug: http://b/31251721
Change-Id: Id0e4379e0efb7194a2df7bd16211ff11c6598033
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
The special case for absolute paths wasn't handling ENOEXEC.
Also add more extensive tests for execvpe.
Also switch to manually doing the fork in ExecTestHelper::Run because
ASSERT_EXIT doesn't actually return, meaning we were only running the
first part of each test.
Bug: http://b/31073104
Change-Id: I7a4640afc6d290c51ba2e66fc1b9bb6b0fc174f7
Also fix <sys/ipc.h>.
Not useful except to systems/bringup folks for testing. Trivial tests
added, and double-checked under strace to see that things look right.
x86 -- which works differently to everything else -- tested on the host.
Bug: http://b/27952303
Change-Id: I328534e994ae9e90755f545478fba03038c0bb94
We already had implementations of some of the functions, and I didn't
bother rewriting them when we added sysinfo(2). Ross Anderson said in
https://www.lightbluetouchpaper.org/2016/07/29/yet-another-android-side-channel/
that we should "simply disable access to all procfs files", which made
me curious how many places we use /proc in bionic. This is the one that's
obviously unnecessary. The others I'm not aware of alternative APIs for.
Change-Id: Ia64f36b76f29a7a1dd67845270a5472e121aae10
Hiding our legacy cruft seemed like a good idea, but in practice it will only
mean worse interoperability.
Plus we got it wrong, as the recent `putw` example showed.
Change-Id: I167c7168eff133889028089c22a7a0dfb8d6d0cf
This change implements the following property:
Any 2**N aligned memory region on size 2**N contains no more than one DSO.
The value N can be configured, with 16 or 18 looking like a good choice.
Additionally, DSOs are loaded at random page-aligned address inside these large
regions.
This change has dual purpose:
1. Larger values of N allow a lot more compact CFI shadow implementation.
See change I14dfea630de468eb5620e7f55f92b1397ba06217.
For example, CFI shadow for the system_server process has the following size (RSS, KB):
152 for N = 12, 32 for N = 16, 16 for N = 18.
2. Extra randomization is good for security.
This change does not result in extra RAM usage, because everything is still page-aligned.
It does result in a bit more VM fragmentation because of the gaps between shared libraries.
As it turns out, this fragmentation is barely noticeable because the kernel creates new mapping
at the highest possible address, and we do enough small mappings to almost completely fill the
gaps (ex. in the Zygote the gaps are filled with .ttf file mappings and thread stacks).
I've measured VM fragmentation as the sum of all VM gaps (unmapped regions) that are larger
than 1MB according to /proc/$PID/maps. On aosp_angler-userdebug, the numbers are (in GB):
| N = 12 | N = 18
system_server | 521.9 | 521.1
zygote64 | 522.1 | 521.3
zygote32 | 2.55 | 2.55
mediaserver | 4.00 | 4.00
Change-Id: Ia6df840dd409c82837efd1f263be420d9723c84a
Previous patch changed pthread_cond_timedwait_relative_np to use
CLOCK_REALTIME, which causes app compatibility problem. So change
it back to CLOCK_MONOTONIC.
Bug: 30106240
Change-Id: I8e04058e92ede098f4f9f8d133f094001921441e
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
Spotted these while cleaning up <sys/cdefs.h> --- if we remove __USE_XOPEN2K8,
libchrome decides you "must" have futimes. Adding the missing functions (all
just alternative interfaces to utimensat(2) system call) lets us clean up
without breaking anything.
Change-Id: If44fab08ee3de0e31066d650d128a3c96323529b
There's no change to the generated stubs, because the script only cares
that this is a pointer type, not what it's a pointer to.
Change-Id: I766720965f0f3d201fc90677a076b26870485377
Move everything to where it should be.
Along the way, we lose <net/ethertypes.h>. glibc only has a handful of these
types, and they're all in <net/ethernet.h>, not <net/ethertypes.h>. I've taken
the liberty of not including the AppleTalk ones, since it is 2016.
Also, <net/if_ether.h> should be <netinet/if_ether.h> (though with different
contents).
Bug: http://b/28519060
Change-Id: Ia41c3fc136fd3e6b008c8d08018e0629134ea6fc
* Allow clone where both the child function and stack are null. It's
obviously wrong to ask to call a function without a stack, but it's not
necessarily wrong to supply no stack if you're also not supplying a
function.
* Reimplement fork in terms of the clone function, rather than using the
clone system call directly.
This is intended as a step towards enabling use of pid namespaces.
Change-Id: I03c89bd1dc540d8b4ed1c8fdf6644290744b9e91
http://clang.llvm.org/docs/AttributeReference.html#nonnull
_Nonnull is similar to the nonnull attribute in that it will instruct
compilers to warn the user if it can prove that a null argument is
being passed. Unlike the nonnull attribute, this annotation indicated
that a value *should not* be null, not that it *cannot* be null, or
even that the behavior is undefined. The important distinction is that
the optimizer will perform surprising optimizations like the
following:
void foo(void*) __attribute__(nonnull, 1);
int bar(int* p) {
foo(p);
// The following null check will be elided because nonnull
// attribute means that, since we call foo with p, p can be
// assumed to not be null. Thus this will crash if we are called
// with a null pointer.
if (src != NULL) {
return *p;
}
return 0;
}
int main() {
return bar(NULL);
}
Note that by doing this we are no longer attaching any sort of
attribute for GCC (GCC doesn't support attaching nonnull directly to a
parameter, only to the function and naming the arguments
positionally). This means we won't be getting a warning for this case
from GCC any more. People that listen to warnings tend to use clang
anyway, and we're quickly moving toward that as the default, so this
seems to be an acceptable tradeoff.
Change-Id: Ie05fe7cec2f19a082c1defb303f82bcf9241b88d
* Fix the return type of towlower_l/towupper_l.
* Implement wctrans/wctrans_l/towctrans/towctrans_l.
* Move declarations that POSIX says are available from both <wchar.h> and
<wctype.h> to <bits/wctype.h> and include from both POSIX headers.
* Write the missing tests.
Change-Id: I3221da5f3d7e8a2fb0a7619dc724de45f7b55398
Not efficient to iterate through given the large number of Android
ids (AID). Compile warning will result if you use these functions,
telling you as much. Not for general consumption, however for
example, some filesystem tests would like to see these to perform
all corners.
About 1/4 second for getpwent, and 1/8 second for getgrent to iterate
through all reserved Android aids.
Bug: 27999086
Change-Id: I7784273b7875c38e4954ae21d314f35e4bf8c2fc
* changes:
Move <sys/sysconf.h> to <bits/sysconf.h>.
Remove mbstowcs from <wchar.h>.
Extract getopt and friends to <bits/getopt.h>
Remove declaration of unlinkat from <fcntl.h>.
Extract ioctl to <bits/ioctl.h>.
Extract fcntl to <bits/fcntl.h>.
Extract strcasecmp and friends to <bits/strcasecmp.h>.
Make <bits/lockf.h> compile standalone.
Make <android/dlext.h> compile standalone.
Make the network headers compile standalone.
Remove duplicate declaration of mlock, munlock.
The XXXX now lines up to the underlying uid and has no offset.
Work with AID_OEM_RESERVED uids.
Test uses hard coded values to catch changes in the API expectations
that may occur in private/android_filesystem_config.h.
SideEffects: names change, some product dependencies.
Bug: 27999086
Change-Id: Ic2b4c36de74ae009a44e14711c75834293828207
- added grp_pwd.cpp containing POSIX passwd and group functions,
colocated because they share with the Android ID (AID) roots.
- stubs.cpp contains all the truly empty functions (network and
protocol accessors)
Bug: 27999086
Change-Id: I036f9e2dd246f48302cb7c97d23176fa24d19c33
Implement the legacy SysV signal handling functions sighold(),
sigignore(), sigpause(), sigrelse(), and sigset() in terms of the newer
POSIX signal APIs. As of POSIX 2013 the SysV signal APIs are deprecated
but still required.
Change-Id: I4ca40e3d706605a7d1a30dc76c78b2b24586387d
Signed-off-by: Greg Hackmann <ghackmann@google.com>
The code to calculate thread stack and signal stack looks weird:
the thread stack size and signal stack size are related with
each other on 32-bit mode, but not on 64-bit mode. So change the
code to make the logic more resonable. This doesn't change anything
as we have defined SIGSTKSZ to 16K on arm64.
Bug: 28005110
Change-Id: I04d2488cfb96ee7e2d894d062c66cef950fec418
This function only exists for backwards compatibility, so leave it as it was.
Bug: http://b/26944282
Change-Id: I31973d1402660933103ee2d815649ab9569e4dfc
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
POSIX makes "the CPU-time clock of the calling thread" (i.e.,
CLOCK_THREAD_CPUTIME_ID) a special case which returns EINVAL instead of
ENOTSUP.
However, the clock_nanosleep syscall treats this clock just like any
other, and returns -EOPNOTSUPP to indicate an unimplemented nanosleep
handler. So we need to handle this ourselves in userspace.
This change fixes the LTP clock_nanosleep01 testcase.
Change-Id: If3bed940d276834bcd114d8c17f96197e9384711
Signed-off-by: Greg Hackmann <ghackmann@google.com>
bionic has the Linux-specific mntent.h but is missing hasmntopt().
Change-Id: I0ab7b83626c969704add4e64b37a6fc715d4a723
Signed-off-by: Greg Hackmann <ghackmann@google.com>
{get,set}domainname aren't in POSIX but are widely-implemented
extensions.
The Linux kernel provides a setdomainname syscall but not a symmetric
getdomainname syscall, since it expects userspace to get the domain name
from uname(2).
Change-Id: I96726c242f4bb646c130b361688328b0b97269a0
Signed-off-by: Greg Hackmann <ghackmann@google.com>
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>
Even though the size parameter to epoll_create(2) is (otherwise) unused,
passing in size <= 0 is explicitly documented as an error.
This change fixes the LTP epoll01 testcase.
Change-Id: I044a38be823c2fa956b57e77cc66571dfae8a4bb
Signed-off-by: Greg Hackmann <ghackmann@google.com>
The clone syscall accepts NULL child stacks, interpreting this to mean
the child gets a copy of the parent's stack with copy-on-write
semantics. However clone(2) is explicitly documented to treat this an
an error.
"Fortunately" every architecture's __bionic_clone implementation pushes
something onto the child stack before making the clone syscall. So we
know fixing this won't break legacy apps, because any app that tried
using a NULL child stack would have died with SIGSEGV.
This change fixes the LTP clone04 testcase.
Change-Id: I663b34f34bc8dad2aa405c46e4eed4418cccca0d
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Also guard both these GNU extensions with _GNU_SOURCE.
Also improve the tests to test each case on both the current thread and
another thread, since the code paths are totally different.
Bug: http://b/27810459
Change-Id: I72b05bca5c5b6ca8ba4585b8edfb716a1c252f92
We don't have a compile-time limit on the number of threads,
and we don't have a definite run-time limit either.
Bug: http://b/27617302
Change-Id: I6a6fe083e7b655d24eb9e7ef7f3e0280d483080b
Do not initialize all of the global function pointers associated with
debug malloc until the initialization has completed correctly.
Bug: 27600760
Change-Id: I0621b54bc2d9fab63805d7992d384e550d6fed2a
Don't ask the kernel to copy data to userspace if we don't need it.
(Noticed while cleaning up sysconf to not call clock_getres.)
Change-Id: Icc0f7559775b8a2dcefe638ce831d06b75d67122
There are a hundred other reasons why we can't run on kernels old enough
to not have all the clocks covered by sysconf.
This was causing trouble for jemalloc 4.1.0 in a seccomp-constrained process
because jemalloc 4.1.0 introduced a call to sysconf that caused us to make
clock_getres syscalls for the first time, leading to SIGSYS.
Bug: http://b/27408522
Change-Id: I2eb6986d871bc03cbef278e5617734409c39e057
glibc, FreeBSD, OpenBSD, and Darwin all just leave the fd unchanged and
possibly uninitialized. Setting it to -1 seems friendlier, though.
Bug: http://b/27506278
Change-Id: I7acdc8eecbea4404d5fb4ba0b4d572245a323886
Make it easier to diagnose applications mucking with the contents of
jmp_buf by checksumming its contents.
Bug: http://b/27417786
Change-Id: I9989e2ea3979a36ae0bc4c9e1bacafddbacc731b
This involves actually implementing assembler __memset_chk for arm64,
but that's easily done.
Obviously I'd like this for all architectures (and all the string functions),
but this is low-hanging fruit...
Change-Id: I70ec48c91aafd1f0feb974a2555c51611de9ef82
Also remove an if that implied that IFA_BROADCAST is a possibility for
AF_INET6.
The existing tests fail if you have a point-to-point interface configured,
so no new test necessary.
Bug: http://b/27442503
Change-Id: I4c5823b32204ae6c15527853414c2a0cef320b53
Our FORTIFY _chk functions' implementations were very repetitive and verbose
but not very helpful. We'd also screwed up and put the SSIZE_MAX checks where
they would never fire unless you actually had a buffer as large as half your
address space, which probably doesn't happen very often.
Factor out the duplication and take the opportunity to actually show details
like how big the overrun buffer was, or by how much it was overrun.
Also remove the obsolete FORTIFY event logging.
Also remove the unused __libc_fatal_no_abort.
This change doesn't improve the diagnostics from the optimized assembler
implementations.
Change-Id: I176a90701395404d50975b547a00bd2c654e1252
...so memset it is, then.
I'll be glad when GCC is dead and we can use "= {}" like it's the 21st century.
Change-Id: I28d820d3926ac9bf44bf7c1e89e184726c840391
The purpose of this change is to silence Valgrind's warning about a
syscall parameter pointing to uninitialised bytes.
Change-Id: I2737235f9ac288dbc8ec4be0c6f1cef181c9b7d7
Add backtrace_string to convert a malloc_debug backtrace to a string.
Also move the backtrace functions to libc_malloc_debug_backtrace so that
libmemunreachable can reuse them.
Change-Id: I5ad67001c0b4d184903c762863a8588181d4873b
Since we set both fields to NULL all the time, we can alias the two
fields together on LP32 to provide build-time compatibility.
BUG=24918750
TEST=python now builds for Brillo boards
Change-Id: I3394aea80c9a5288669389f71d0e4132f2157e3c
Check if thread_id is in fact pthread_self before
locking on g_thread_list_lock in __pthread_internal_find.
The main reason for doing this is not performance but to allow
the linker use raise() which was not working because pthread_kill()
couldn't find pthread_self() thread because the global thread
list is initialized in libc.so and the linker's version of this
list is empty.
Bug: http://b/25867917
Change-Id: I18fe620e8cd465b30f0e1ff45fff32958f3c5c00
Our fopen/freopen/tmpfile are already always O_LARGEFILE, but let's add
the aliases for _LARGEFILE_SOURCE compatibility.
Bug: http://b/24807045
Change-Id: I5d99b3ef3c9f27ce70f13313f6a92e96c7f21f80
This file should have been deleted with the malloc debug rewrite, but
popped back into existence due to a merge conflict.
Change-Id: I74e53daaf3febf650b20e3da5329558ac84c5bcd
If snprintf() is called from the linker, it may erroneously return a
null string. The libc internal __libc_format_buffer() does not have
this problem, so it is now used instead.
Bug: 26756577
Change-Id: I37a97e27f59b3c0a087f54a6603cc3aff7f07522
This has been requested a few times over the years. This is basically
a very late rebase of https://android-review.googlesource.com/45470
which was abandoned years ago. One addition is that this version has
_FILE_OFFSET_BITS=64 support.
POSIX puts this in <unistd.h>. glibc also has it in <fcntl.h>.
Bug: http://b/13077650
Change-Id: I5862b1dc326e326c01ad92438ecc1578d19ba739
Broke the build. There's no such file as bionic_sdk_version.h anywhere in the tree.
This reverts commit 892b61d340.
Change-Id: Iec3f4588edfb1d1524bb5f16451fd05dc6ebe44a
Posix standards says sem_wait is interruptible by the delivery
of a signal. To keep compatiblity with old apps, only fix that
in newer sdk versions.
Bug: 26743454
Change-Id: I924cbb436658e3e0f397c922d866ece99b8241a3
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
This is just a subset of the recently-implemented getifaddrs(3), though if
we want to handle interfaces (such as "rmnet_*") that don't have an address,
we need to either expose ifaddrs_storage and keep track of which interfaces
we've already seen (which is pretty messy), or refactor the netlink code so
we can reuse it and just extract the information we need for if_nameindex(3).
This patch goes the latter route.
Also clean up if_nametoindex(3) and if_indextoname(3).
Change-Id: I5ffc5df0bab62286cdda2e7af06f032c767119a8
Also fix a bug where we were mutating the address/broadcast address
of an existing entry rather than the new entry, and use 'const' to
ensure we don't make that mistake again.
Change-Id: I31c127a5d21879b52c85cd0f7ed2e66554a21e39
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
Currently, reads of ro.* properties are treated differently than
writes of ro.* properties. When writing an ro.* property, we ignore
the "ro." portion of the property, and base the security decision
on the label of the remaining portion.
See e7a9e52740/init/property_service.cpp
line 120-126
For example, for writing, the label associated with
"ro.build.fingerprint" comes from the /property_contexts file
entry:
# ro.build.fingerprint is either set in /system/build.prop, or is
# set at runtime by system_server.
build.fingerprint u:object_r:fingerprint_prop:s0
However, we fail to follow this same special case when sorting
properties into files. Instead, ro.build.fingerprint is assigned
u:object_r:default_prop:s0 instead of u:object_r:fingerprint_prop:s0
Ignore the "ro." portion when sorting properties into files.
This will make reads and writes of properties use the same label.
Bug: 21852512
Change-Id: Ie88ffc6b78b31fc8ddf370ae27c218546fb25a83
This reverts commit 76814a8250.
This differs from the original in fixing the GCC -Werror build:
bionic/libc/bionic/ifaddrs.cpp: In function 'void __handle_netlink_response(ifaddrs**, nlmsghdr*)':
bionic/libc/bionic/ifaddrs.cpp:113:62: error: use of old-style cast [-Werror=old-style-cast]
ifinfomsg* ifi = reinterpret_cast<ifinfomsg*>(NLMSG_DATA(hdr));
This appears to be a GCC bug; the GCC command-line correctly uses -isystem,
and manually adding #pragma GCC system_header doesn't help. So just turn the
warning off for GCC for now. We won't need to worry about building with GCC
soon anyway.
Bug: http://b/26238832
Change-Id: I01615bd335edf11baf487b1c83a9157cd780f4a1
Time to dust off the old libcore implementation from gingerbread and add it
to bionic. Unlike the original, this actually looks at both RTM_NEWLINK and
RTM_NEWADDR.
Bug: http://b/26238832
Change-Id: I7bb4b432deb766065b66b9c9ff36ed68249aba82
It actually means "crash immediately". Well, it's an error. And callers are
much more likely to realize their mistake if we crash immediately rather
than return EINVAL. Historically, glibc has crashed and bionic -- before
the recent changes -- returned EINVAL, so this is a behavior change.
Change-Id: I0c2373a6703b20b8a97aacc1e66368a5885e8c51
This change removes endpwent, dlmalloc_inspect_all, dlmalloc_trim
from lp64 libc.so. It also removed necessety of having brillo
version scripts for lp64 platforms.
Bug: http://b/26164862
Change-Id: I4e9b38907bb1dc410f0eb6d2f5d5944fe713da51
