Return EAGAIN rather than aborting if we fail to set up the TLS for a new
thread.
Add a test that uses all the VMAs so we can properly test these edge cases.
Add an explicit test for pthread_attr_setdetachstate, which we use in the
previous test, but other than that has no tests.
Remove support for ro.logd.timestamp/persist.logd.timestamp, which doesn't
seem to be used, and which prevents us from logging failures in cases where
mmap fails (because we need to mmap in the system property implementation).
Bug: http://b/65608572
Test: ran tests
Change-Id: I9009f06546e1c2cc55eff996d08b55eff3482343
This also fixes a long-standing bug where the guard region would be taken
out of the stack itself, rather than being -- as POSIX demands -- additional
space after the stack. Historically a 128KiB stack with a 256KiB guard would
have given you an immediate crash.
Bug: http://b/38413813
Test: builds, boots
Change-Id: Idd12a3899be1d92fea3d3e0fa6882ca2216bd79c
(Where errno is relevant.)
Also consistently use -1 as the fd for anonymous mmaps. (It doesn't matter,
but it's more common, and potentially more intention-revealing.)
Bug: http://b/65608572
Test: ran tests
Change-Id: Ie9a207632d8242f42086ba3ca862519014c3c102
We can cut a lot of stuff out of the NDK's libandroid_support with this,
and reduce unnecessary relocations for all LP32 code. LP64 code should
be unaffected.
Bug: https://issuetracker.google.com/64450768
Bug: https://github.com/android-ndk/ndk/issues/507
Test: ran tests, plus manual readelf on the _test.o files
Change-Id: I3de6015921195304ea9c829ef31665cd34664066
For treble enabled devices, still return the appropriate shell depending
on whether the process is a vendor process or a system one.
Test: Manual testing: on a bullhead device, ran test programs from
/vendor/bin which used popen() and system(). The calls succeeded.
Bug: 65054230
Bug: 64516799
Merged-In: I15dfdbb107cfca7c0f92f337c9bb46b9876eb38e
Change-Id: I15dfdbb107cfca7c0f92f337c9bb46b9876eb38e
(cherry picked from commit 1e52871773)
I'm unable to find a bug, but we've had requests for this internally
once or twice (though I pointed those folks at the STL), and there's
code we build for the host or in our bootloaders that would use this,
and there's reasonable-looking FreeBSD implementation ready and waiting.
Bug: N/A
Test: ran tests
Change-Id: I6ddee4b71bea4c22ed015debd31d3eaac4fcdd35
On LP32 mem_unit will be 4096 to allow more than 4GiB in the "ulong"
fields, but we need to promote to a 64-bit type before we multiply.
Bug: N/A
Test: tested manually with an x86 static binary on my 64GiB desktop.
Signed-off-by: YiPing Xu <xuyiping@hisilicon.com>
Change-Id: Id663932503b75793bb7c26a008129f3e2e4cccbf
This used to be used by the ARM longjmp implementation, but hasn't been in
libc.so for as long as we've used a linker script.
Bug: N/A
Test: builds
Change-Id: I3dff4d154d5e317955c349c9eaa08b982cbf0285
libc++ actually provides overloads for all the standard C library stuff,
so we just need to handle the POSIX and GNU extensions, of which there
are just two more: memrchr and strcasestr.
Bug: http://b/22768375
Test: builds
Change-Id: Ie9ed1fbcc794e14a0c9bba13b5307ad677949613
Library calls like system() and popen() invoke the shell executable
pointed to by '_PATH_BSHELL' in order to run the command passed into the
function. The _PATH_BSHELL points to /system/bin/sh by default and thus
breaks any vendor process trying to use system() / popen(), as they are
denied access to system shell by selinux.
This CL make necessary changes, so the implmentations of system() and popen()
can use the appropriate shell (e.g. /vendor/bin/sh for processes running
out of /vendor partition). Also, changes the implementation of system()
and popen().
Bug: 64832610
Test: Manual, Using a test program running from /system/bin and
/vendor/bin to ensure correct shell is being used.
Change-Id: Ie7168d69decb1ae98284446ae7db34dec930dc33
Merged-In: Ie7168d69decb1ae98284446ae7db34dec930dc33
Signed-off-by: Sandeep Patil <sspatil@google.com>
(cherry picked from commit aa3e32422c)
pthread's and semaphore's default behavior is to use CLOCK_REALTIME,
however this behavior is essentially never intended, as that clock is
prone to change discontinuously.
What users really intend is to use CLOCK_MONOTONIC, however only
pthread_cond_timedwait() provides this as an option and even there, a
large amount of existing code does not opt into CLOCK_MONOTONIC.
We have seen numerous bugs directly attributable to this difference.
Therefore, we provide this general workaround to always use
CLOCK_MONOTONIC for waiting, regardless of what the input timespec
is.
Specifically this impacts the below APIs:
pthread_mutex_timedlock()
pthread_cond_timedwait()
pthread_rwlock_timedrdlock()
pthread_rwlock_timedwrlock()
sem_timedwait()
Test: boot bullhead, boot sailfish
Test: bionic pthread/semaphore unit tests
Test: check that pthread_cond_timedwait() timeouts are uneffected by
CLOCK_REALTIME time changes
Bug: 64694413
Bug: 64623895
Bug: 35756266
Bug: 35678943
Change-Id: Ibba98f5d88be1c306d14e9b9366302ecbef6d534
Strictly, the mode isn't really meaningful unless you supply O_EXCL,
but the kernel will take it and fstat will return it even if you
never give the file a name.
Also warn for O_TMPFILE without a mode at compile time where possible.
Bug: N/A
Test: ran tests
Change-Id: I729b6d6e6190676fd017a1190b6200bf9abdbfd8
This also has a handful of style fixups, to make this file more
consistent. And removes __bionic_zero_size_is_okay_t, since there's a
better workaround available.
Bug: 12231437
Test: m checkbuild on bionic internal master; CtsBionicTestCases show
no new failures.
Change-Id: I75a020630dbab0ce828563502900cba14ae992d1
We've never really used __restrict: only <string.h> and <stdio.h> (which
are still very similar to upstream BSD headers) consistently have these
annotations. Neither clang nor GCC warns for trivial cases, and there's
little obvious documentation benefit.
Bug: http://b/30833514
Test: builds
Change-Id: I3e4384281865475d0c55d764b546d8166419ee31
This addresses post-commit feedback from
I88c39ca166bacde0b692aa3063e743bb046a5d2f. With this, our FORTIFY impl
now sits in one file.
Bug: 12231437
Test: mma; no new CtsBionicTestCases failures on bullhead internal
master.
Change-Id: I6f9ff81c3e86cf9d6a0efa650eb5765f1e2fa09c
As requested in the bug. This also rips __memcpy_chk out of memcpy.S,
which lets us cut down on copypasta (all of the implementations look
identical).
Bug: 12231437
Test: mma on aosp_{arm,arm64,mips,x86,x86_64} internal master;
checkbuild on bullhead internal master; CtsBionicTestCases on bullhead.
No new failures.
Change-Id: I88c39ca166bacde0b692aa3063e743bb046a5d2f
AFAICT, all of these were added prior to the new-style FORTIFY going
in. Because clang saw two definitions of the "same" function, it got
upset. (e.g. 35d937e4eb)
Now that our FORTIFY functions are overloads of their library functions,
these undefs can be removed.
(This is a step toward making FORTIFY a library with -U_FORTIFY_SOURCE
on it, as requested in the bug.)
Bug: 12231437
Test: CtsBionicUnitTests. No new failures.
Change-Id: I844ff77106ee2bea72ae1cd0bb85d146939ecd05
...by inlining them.
Also fix a couple of harmless bugs in passing. I've added tests, but in
both cases I don't think it was actually possible to hit the bad behavior:
we'd hit another test and fail immediately after in an externally
indistinguishable way.
Bug: N/A
Test: readelf
Change-Id: I8466050b0bfe2b7b94c76b383cf10c1d9d28debd
We don't need these in libandroid_support, but we do need the other
parts of wchar.cpp, and they're not really related.
Test: make checkbuild
Bug: None
Change-Id: I40f3089b034abfd4873e81c0b6216a7cfd977d8d
libandroid_support shouldn't be using Bionic's TLS slot. Add a
thread_local based implementation. We can't use the thread_local
implementation in bionic because the linker needs this and pthread
thread-locals (which is how thread_local is implemented) doesn't work
that early.
Test: make checkbuild
Test: adb shell /data/nativetest/bionic-unit-tests/bionic-unit-tests
Bug: https://github.com/android-ndk/ndk/issues/300
Change-Id: I7dcbf554ade2264d541d722fa3f86df04926e67a
Upstream's killpg is diverging further from glibc behavior, so let's just fork.
Bug: N/A
Test: ran tests
Change-Id: I70a3543018bc0a5c0bbf019ac527043b90568fda
Before this change we have the old NDK inline termios functions with the
modern constants. Unfortunately the old NDK inline functions relied on
hacking the constants. Fix things by sharing the implementation between
the platform and the NDK headers.
Bug: https://github.com/android-ndk/ndk/issues/441
Test: ran tests
Change-Id: I2773634059530bc954167f29c4783413a2294d5a
Warnings:
bionic/libc/bionic/fts.c:722:5: warning: Null passed to a callee that
requires a non-null 1st parameter
bionic/libc/bionic/sched_cpualloc.c:34:25: warning: Result of 'malloc'
is converted to a pointer of type 'cpu_set_t', which is incompatible
with sizeof operand type 'unsigned long'
bionic/linker/linker_main.cpp:315:7: warning: Access to field 'e_type'
results in a dereference of a null pointer (loaded from variable
'elf_hdr')
bionic/linker/linker_main.cpp:493:66: warning: Access to field 'e_phoff'
results in a dereference of a null pointer (loaded from variable
'elf_hdr')
bionic/linker/linker_main.cpp:90:14: warning: Access to field 'next'
results in a dereference of a null pointer (loaded from variable 'prev')
Bug: None
Test: mma; analyzer warnings are gone. CtsBionicTestCases pass.
Change-Id: I699a60c2c6f64c50b9ea06848a680c98a8abb44a
__libc_preinit sets up the stack protector global cookie value, and thus
cannot intialize a stack protector cookie for itself in the function
prologue. LTO compilation can inline functions requiring a stack
protector into __libc_preinit. This patch disables stack protection for
__libc_preinit and forces all potentially inlined functions into a
helper that can have a stack protector.
Test: run bionic-unit-tests
Change-Id: I45911611190f216c91eb6feff722967214c5f99f
With this, stack frame 0 is the abort, not tgkill.
arm:
#00 pc 0001a41c /system/lib/libc.so (abort+63)
arm64:
#00 pc 000000000001d75c /system/lib64/libc.so (abort+120)
Also "include what you use" for <sys/syscall.h>.
Bug: N/A
Test: ran `crasher abort` and `crasher64 abort`
Change-Id: I6517ac67b39b4133e890d52efc115071c812958b
No other C library expose these, and I couldn't find any callers.
Bug: http://b/62531921
Test: builds
Change-Id: I4a3505bc0897286a4036c48066b98d16665b573a
This breaks code that declares `errno` itself for whatever crazy reason:
b.c:22:12: error: conflicting types for '__errno'
extern int errno;
^
/usr/local/google/ndkports/toolchain/bin/../sysroot/usr/include/errno.h:47:20: note: expanded from macro 'errno'
#define errno (*__errno())
^
/usr/local/google/ndkports/toolchain/bin/../sysroot/usr/include/errno.h:44:15: note: previous declaration is here
volatile int* __errno(void) __attribute_const__;
^
Bug: N/A
Test: built various bits of GNU source
Change-Id: I27c03bf3bde419a001f98f1ea6c267c847f31271
File libc/SYSCALLS.TXT is updated to generate bionic's system call wrappers
for clock_gettime() & gettimeofday() that will be called if kernel vdso
implementations fail to execute.
The system call wrappers are generated using a python script gensyscalls.py.
Since all architectures support vdso now, there is no more need for conditional
statements regarding supported architectures in libc/bionic/vdso.cpp &
libc/private/bionic_vdso.h files.
Test: builds
Change-Id: I7213f29c179a7929851499d78a72900638ae861a
Signed-off-by: Goran Ferenc <goran.ferenc@imgtec.com>
/vendor is not mounted in recovery and so the property initialization
must not fail if the vendor property context is not found.
Bug: 38212419
Test: boot into recovery, mount system and run adb shell getprop
Change-Id: I9f7c2fe2b20da86194eff8e7bf94b2352e50bf27
Signed-off-by: Sandeep Patil <sspatil@google.com>
Add the mallopt function, and only a single option so far.
Bug: 36401135
Test: Built and booted bullhead.
Test: Ran jemalloc unit tests.
Test: Ran bionic unit tests.
Test: Ran a test that allocated and free'd a large piece of memory,
Test: and verified that after changing the parameter, the PSS
Test: sticks around (decay timer set to 1), the PSS is purged (decay
Test: timer set to 0).
Change-Id: I6927929b0c539c1023d34772d9e26bb6a8a45877
__isthreaded is annoying for ARC++ and useless for everyone. Just hard-code
the value in ndk_cruft for LP32 and be done with it.
Bug: N/A
Test: builds
Change-Id: I08f11a404bbec55ed57cb1e18b5116163c7d7d13
Switch raise to using tgkill with direct syscalls of getpid/gettid,
and switch abort to use raise(SIGABRT).
Bug: http://b/37769298
Test: debuggerd_test
Change-Id: If6f9d17fd8ae6177e742dc9f2f44bd78539431ba
(cherry picked from commit bf2af69fb2)
Switch raise to using tgkill with direct syscalls of getpid/gettid,
and switch abort to use raise(SIGABRT).
Bug: http://b/37769298
Test: debuggerd_test
Change-Id: If6f9d17fd8ae6177e742dc9f2f44bd78539431ba
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
Netflix was using this, and looking the header file, although
__system_property_find_nth has been available since the beginning of time,
__system_property_foreach only appeared in 16. So anyone who wants to run
on pre-JellyBean devices would want to use __system_property_find_nth.
It's pretty much a one-liner in terms of __system_property_foreach anyway,
so it doesn't cost us anything to keep it.
Also restore slightly better tests than we originally removed.
Bug: http://b/36566667
Test: ran tests
(cherry picked from commit 438e01940b)
Change-Id: I639f2142ad4ba049b990b13ccccd255be4b4f479
Netflix was using this, and looking the header file, although
__system_property_find_nth has been available since the beginning of time,
__system_property_foreach only appeared in 16. So anyone who wants to run
on pre-JellyBean devices would want to use __system_property_find_nth.
It's pretty much a one-liner in terms of __system_property_foreach anyway,
so it doesn't cost us anything to keep it.
Also restore slightly better tests than we originally removed.
Bug: http://b/36566667
Test: ran tests
Change-Id: Id268c2c2e848da17bb0a5a5420af234d9dcb829a
This is the last bionic caller that was manually trying to cache
property values.
Bug: N/A
Test: builds and boots
Change-Id: Id66c0a05d8448f08c39dbf7189241e75615d44b4
We're currently reporting errno from the clean up call to close(),
which is much less interesting than the failing connect() call that
precedes it. This change reports errno from the connect() call
instead.
Bug: 36249702
Test: Boot bullhead, bionic unit tests
Test: Fake bad end point and see relevant error returned
Change-Id: Icadec463f50cd0a2a2faa08f049a7996cd32786f
User code on a non-treble device was starting with errno == ENOENT rather
than 0 because of this treble support:
openat(AT_FDCWD, "/property_contexts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
faccessat(AT_FDCWD, "/system/etc/selinux/plat_property_contexts", R_OK) = -1 ENOENT (No such file or directory)
This caused us to fail some toybox tests by reporting bogus errno values
where errno should have been left unset:
PASS: date -d @0
FAIL: date -d @0x123
echo -ne '' | TZ=UTC date -d @0x123 2>&1
--- expected
+++ actual
@@ -1 +1 @@
-date: bad date '@0x123'
+date: bad date '@0x123': No such file or directory
PASS: date -d 06021234
PASS: date -d 060212341982
FAIL: date -d 123
echo -ne '' | TZ=UTC date -d 123 2>&1
--- expected
+++ actual
@@ -1 +1 @@
-date: bad date '123'
+date: bad date '123': No such file or directory
PASS: date -d 1110143115.30
PASS: date -d 111014312015.30
PASS: date Unix time missing @
Bug: http://b/37248982
Test: ran tests
(cherry picked from commit 7ade61cae2)
Change-Id: I4c680da14f3df16dc5a9884071e48f3221ad3b3b
User code on a non-treble device was starting with errno == ENOENT rather
than 0 because of this treble support:
openat(AT_FDCWD, "/property_contexts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
faccessat(AT_FDCWD, "/system/etc/selinux/plat_property_contexts", R_OK) = -1 ENOENT (No such file or directory)
This caused us to fail some toybox tests by reporting bogus errno values
where errno should have been left unset:
PASS: date -d @0
FAIL: date -d @0x123
echo -ne '' | TZ=UTC date -d @0x123 2>&1
--- expected
+++ actual
@@ -1 +1 @@
-date: bad date '@0x123'
+date: bad date '@0x123': No such file or directory
PASS: date -d 06021234
PASS: date -d 060212341982
FAIL: date -d 123
echo -ne '' | TZ=UTC date -d 123 2>&1
--- expected
+++ actual
@@ -1 +1 @@
-date: bad date '123'
+date: bad date '123': No such file or directory
PASS: date -d 1110143115.30
PASS: date -d 111014312015.30
PASS: date Unix time missing @
Bug: http://b/37248982
Test: ran tests
Change-Id: Iacf08c89dbe207ec53a7837e6ac7f78f5541ef35
libcxx provides const-correct overloads for a few string.h functions.
These overloads use clang's enable_if attribute, so they're preferred
over our FORTIFY'ed equivalents.
This weakens _FORTIFY_SOURCE=2 when used with some of these functions,
since clang needs to see __pass_object_size in order to pass an accurate
result for __builtin_object_size(s, 1) at a callsite. Since those
functions don't have __pass_object_size on their params, clang can't do
that. This makes LLVM lower the __builtin_object_size calls, which means
we get the same result as __builtin_object_size(s, 0).
We have to provide all of the overloads in Bionic, since enable_if is
only used to disambiguate overloads with (otherwise) the same type. In
other words:
// overload 1
char *strchr(const char *, int s) __attribute__((enable_if(1, "")));
// overload 2
char *strchr(char *, int s);
void foo() {
char cs[1] = {};
strchr(static_cast<const char *>(cs), '\0'); // calls overload #1.
strchr(cs, '\0'); // calls overload #2.
}
Bug: 34747525
Test: m checkbuild on bullhead internal master + AOSP. vts -m
BionicUnitTests passes on both. Surprisingly, the only code that this
seems to break is contained in Bionic.
Change-Id: Ie406f42fb3d1c5bf940dc857889876fc39b57c90
libc_logging is getting statically linked into the crash handler
library, resulting in two copies of the abort message code existing in
processes, one in the linker, and one in the crash handler.
Move android_set_abort_message to its own file to solve this.
Bug: http://b/36862204
Test: /data/nativetest/debuggerd_test/debuggerd_test32
Change-Id: Ie198c5a3bb07645aa43296915c9a6752693f14a9
(cherry picked from commit 10ec9286ae)
libc_logging is getting statically linked into the crash handler
library, resulting in two copies of the abort message code existing in
processes, one in the linker, and one in the crash handler.
Move android_set_abort_message to its own file to solve this.
Bug: http://b/36862204
Test: /data/nativetest/debuggerd_test/debuggerd_test32
Change-Id: Ie198c5a3bb07645aa43296915c9a6752693f14a9
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
(cherry picked from commit eb04ed506f)
Change-Id: Ie9da1bf4c2dcc23be7d75c739ae8549309813f88
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
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
