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
