setprogname() does a basename, but we were initializing __progname
directly. Stop doing that, and add some tests.
Test: treehugger
Change-Id: I06f306ade4161b2f0c7e314a3b1b30c9420117b7
Use O_PATH like musl to let the kernel do the hard work, rather than the
traditional BSD manual scheme.
Also add the most obvious missing tests from reading the man page, plus
a non-obvious test for deleted files.
Bug: http://b/131435126
Test: treehugger
Change-Id: Ie8a8986fea55f045952a81afee377ce8288a49d5
This reverts commit 43d5f9d4dd.
Bug: 135754954
Bug: 147147490
Exempt-From-Owner-Approval: clean revert
Reason for revert: Breaks ART gtest, see:
https://ci.chromium.org/p/art/builders/ci/angler-armv8-non-gen-cc/561
The crash happens on mprotect of a page, the test crashes with ENOMEM.
Change-Id: I52eea1abbfaf8d8e2226f92d30aa55aba3810528
Bug: 122332847
Bug: 130734182
Test: mmm bionic/tests; same files installed before & after
Test: m cts; same files in cts before & after
Test: `objdump -x <files> | grep NEEDED` is identical
Test: `objdump -x <files> | grep RUNPATH` difference make sense
(additional lib64 entries from soong, minimal reorder)
Test: treehugger
Change-Id: I6eea4c3f9c0040efeba64e2b47c7b573767cd386
This patch introduces tagged pointers to bionic. We add a static tag to
all pointers on arm64 compatible platforms (needs requisite
top-byte-ignore hardware feature and relevant kernel patches).
We dynamically detect TBI-compatible devices (a device with the TBI feature and
kernel support) at process start time, and insert an implementation-dependent
tag into the top byte of the pointer for all heap allocations. We then check
that the tag has not been truncated when deallocating the memory.
If an application incorrectly writes to the top byte of the pointer, we
terminate the process at time of detection. This will allow MTE-incompatible
applications to be caught early.
Bug: 135754954
Bug: 147147490
Test: cd bionic && atest .
Change-Id: I6e5b809fc81f55dd517f845eaf20f3c0ebd4d86e
This patch refactors heapprofd_malloc to make it easier to reuse the
reserved signal for multiple purposes. We define a new generic signal
handler for profilers, which dispatches to more specific logic based on
the signal's payload (si_value).
The profiler signal handler is installed during libc preinit, after
malloc initialization (so races against synchronous heapprofd
initialization need not be considered). In terms of code organization, I
copied the existing approach with a loosely referenced function in
bionic_globals.h. Do tell if you'd rather a different approach here.
The profileability of a process is quite tied to the malloc
files/interfaces in bionic - in particular, it's set through
android_mallopt. I do not change that, but instead introduce a new
android_mallopt option to be able to query profileability of the
process (which is now used by the new profiler signal handler). As part
of that, gZygoteChildProfileable is moved from heapprofd_malloc to
common (alongside gZygoteChild).
I've removed the masking and reraising of the heapprofd signal when
racing against malloc_limit init. We're ok with taking a simpler
approach and dropping the heapprofd signal in such an unlikely race.
Note: this requires a corresponding change in heapprofd to use sigqueue()
instead of kill(), as the latter leaves the si_value uninitialized(?) on
the receiving side.
Bug: 144281346
Change-Id: I93bb2e82cff5870e5ca499cf86439860aca9dfa5
Bug: 146576216
Test: Ran the test on jemalloc and glibc.
Test: Ran the test on scudo and verified that failed without the align
Test: change.
Change-Id: I31a96f8672c6bce2423210300288a13df1eda42a
Before, the helper method for this test had two local variables:
char buf[128];
volatile char* p;
Then the test wrote zeros into the buffer and one past the buffer end.
This relied on the fact that the compiler constructed the stack frame
with 'p' first and then the buffer (and also optimized away the 'size'
variable).
However, some compiler options (namely -ftrivial-auto-var-init=pattern)
result in the stack frame being reordered so that 'p' is actually after
buf, and the test cannot pass.
Fixes: 132780819
Test: bionic-unit-tests-static (w/ w/o flag)
Change-Id: Icc87c02add211c2afb7c96ae22701ec27990364c
Historically we've made a few mistakes where they haven't matched the
right number. And most non-Googlers are much more familiar with the
numbers, so it seems to make sense to rely more on them. Especially in
header files, which we actually expect real people to have to read from
time to time.
Test: treehugger
Change-Id: I0d4a97454ee108de1d32f21df285315c5488d886
The executable flag might not be present for the executable segment
if the code is being handled by native bridge implementation. Old
heuristics for this case was to assume first segment is executable.
This doesn't stand any more. Instead, look for segment that contains
the function test is going to call.
Test: bionic-unit-tests --gtest_filter=dlext.ns_anonymous
Change-Id: I960bebba86e225d739b73f6d093e145fff17b4a8
'kill(pid, sig)' sends signal to arbitrary thread within a process, thus
test was occasionally sending signal to the killing thread, not to the
waiting thread. Use 'tgkill(pid, tid, sig)' instead.
Test: bionic-unit-tests --gtest_filter=signal.sigwait64_SIGRTMIN
Change-Id: I80377295e2362cb87eb4fb4de2489c51c520ea77
With previous sleep time, if unlucky, newly started thread can send
signal before main thread starts sigwait.
Test: bionic-unit-tests --gtest_filter=signal.sigwait64_SIGRTMIN
Change-Id: I63d7825a695988e388903c7951e2435cb69773a1
The code was checking PTRACE_GETREGSET output even in case of error.
This seems not correct. Though ptrace can still write some output in
case of EINVAL, implementation should still check updated iov_len before
reading it.
Change the code to avoid checking output in case of error at all.
Test: bionic-unit-tests --gtest_filter=sys_ptrace.watchpoint_stress
Change-Id: I7b1ca18ac64f81055ff89f56b453aff0ce8e1057
dl#exec_linker* tests are failing on devices with emulated
architecture due to hardcoded path to linker.
Test: bionic-unit-tests --gtest_filter=dl.exec_linker*
Bug: b/141914915
Change-Id: Id6d8d3ee7114e70b07e44034aa62dce0a3e0760e
Signed-off-by: Dmytro Chystiakov <dmytro.chystiakov@intel.com>
In configs like ASAN, we can't use _chk functions. This CL builds off of
previous work to allow us to still emit diagnostics in conditions like
these.
Wasn't 100% sure what a good test story would look like here. Opinions
appreciated.
Bug: 141267932
Test: checkbuild on internal-master. TreeHugger for x86_64.
Change-Id: I65da9ecc9903d51a09f740e38ab413b9beaeed88
For reasons explained in the code comment, go back to roughly our old
code. The "new" tests are just the old tests resurrected.
This also passes the current toybox xargs tests, which were the
motivation for going back on our earlier decision.
Test: bionic and toybox tests
Change-Id: I33cbcc04107efe81fdbc8166dc9ae844e471173e
Right now, when we read a system property, we first (assuming we've
already looked up the property's prop_info) read the property's serial
number; if we find that the low bit (the dirty bit) in the serial
number is set, we futex-wait for that serial number to become
non-dirty. By doing so, we spare readers from seeing partially-updated
property values if they race with the property service's non-atomic
memcpy to the property value slot. (The futex-wait here isn't
essential to the algorithm: spinning while dirty would suffice,
although it'd be somewhat less efficient.)
The problem with this approach is that readers can wait on the
property service process, potentially causing delays due to scheduling
variance. Property reads are not guaranteed to complete in finite time
right now.
This change makes property reads wait-free and ensures that they
complete in finite time in all cases. In the new approach, we prevent
value tearing by backing up each property we're about to modify and
directing readers to the backup copy if they try to read a property
with the dirty bit set.
(The wait freedom is limited to the case of readers racing against
*one* property update. A writer can still delay readers by rapidly
updating a property --- but after this change, readers can't hang due
to PID 1 scheduling delays.)
I considered adding explicit atomic access to short property values,
but between binary compatibility with the existing property database
and the need to carefully handle transitions of property values
between "short" (compatible with atomics) and "long" (incompatible
with atomics) length domains, I figured the complexity wasn't worth it
and that making property reads wait-free would be adequate.
Test: boots
Bug: 143561649
Change-Id: Ifd3108aedba5a4b157b66af6ca0a4ed084bd5982
This reverts commit d7e11b8853.
Reason for revert: Breaks aosp_x86_64-eng. Will look into it and
unbreak when it's not almost midnight. :)
Change-Id: I21f76efe4d19c70d0b14630e441376d359a45b49
When using a FILE object for some malloc debug functions, calling
fprintf will trigger an allocation to be put in the object. The problem
is that these allocations were not allocated by the malloc debug
wrapper and they get freed during the fclose as if they are malloc
debug allocation. In most cases, the code will detect the bad pointer
and leak the memory, but it might also cause a crash.
The fix is to avoid using fprintf so that no allocations are made
in the object that survive and need to be freed in the fclose call.
Change the MallocXmlElem.h to use a file decsriptor not a FILE object.
Add new unit and system tests to detect this case.
Bug: 143742907
Test: Ran unit and system tests.
Test: Ran bionic unit tests.
Change-Id: I524392de822a29483aa5be8f14c680e70033eba2
This change makes it easier to diagnose mistakes in linker
configuration that result in a library being accidentally loaded in
multiple namespaces without its dependencies available everywhere.
Test: manually tested the error message
Test: bionic-unit-tests
Change-Id: I03a20507f8fc902c2445a7fbbf59767ffffd5ebf
In configs like ASAN, we can't use _chk functions. This CL builds off of
previous work to allow us to still emit diagnostics in conditions like
these.
Wasn't 100% sure what a good test story would look like here. Opinions
appreciated.
Bug: 141267932
Test: checkbuild on internal-master
Change-Id: I8d4f77d7b086a8128a18a0a0389243d7fa05b00f
Upstream keeps rearranging the deckchairs for these, so let's just
switch to the [roughly] one-liners rather than track that...
Test: treehugger
Change-Id: If655cf7a7f316657de44d41fadd43a8c55ee6f23
In order for an ifunc resolver to detect the presence of certain CPU features,
access to getauxval(AT_HWCAP) or getauxval(AT_HWCAP2) may be required. In order
for getauxval() to work, it needs to access the pointer to the auxiliary vector
stored by the linker in the libc shared globals data structure. Accessing the
shared globals requires libc to call the __libc_shared_globals() function
exported by the linker. However, in order to call this function, libc must
be fully relocated, which is not guaranteed to be the case at the point when
ifunc resolvers are called.
glibc solves this problem by passing the values of getauxval(AT_HWCAP)
(and getauxval(AT_HWCAP2) on aarch64) as arguments to the ifunc resolver.
Since this seems to be not only the most straightforward way to solve the
problem but also improves our compatibility with glibc, we adopt their
calling convention.
This change is ABI compatible with old resolvers because the arguments are
passed in registers, so the old resolvers will simply ignore the new arguments.
Bug: 135772972
Change-Id: Ie65bd6e7067f0c878df3d348c815fda61dc12de2
This patch decreases created threads to 50 (instead of 90)
on devices with 2 cores CPU. It is a second decrease as this
test case started to fail on same devices after kernel uprev
Bug: b/142210680
Test: Run CtsBionic module on 2 core device with command
"run cts -m CtsBionicTestCases
Change-Id: I4f73363b342b38c92d64aaf213071f899e5b52ac
Signed-off-by: Dmytro Chystiakov <dmytro.chystiakov@intel.com>
I plan to add tests to this test binary that take a long time to run.
The first is a malloc test that demonstrates that jemalloc appears
to be leaking memory slowly over time.
Test: Ran the bionic-stress-tests on host and verified it runs forever,
Test: but doesn't display RSS/VSS data.
Test: Ran the bionic-stress-tests on a taimen and verified it runs forever,
Test: and does display RSS/VSS data.
Change-Id: Ic612e4181ffea898d4d83af097939cd517a180ee
Scudo creates a large map on 64 bit which can cause a slow down trying
to get the usage stats for all maps. Since the test only really cares
about a small subset of maps, only get the usage stats for those maps.
Test: Ran unit tests on scudo and jemalloc based systems.
Change-Id: Iba3cff1487ca304083aac323a3971b9f939f5c11
As the first pass, the malloc_info for scudo doesn't return anything.
This feature is hardly ever used, so this seems fine for the first
revision.
Bug: 137795072
Test: Ran unit tests on a taimen using scudo and a taimen using jemalloc.
Change-Id: I675386ae17ba5505c27bd9da12c60242d795464a
There are places in frameworks and art code that directly included
private bionic header files. Move these files to the new platform
include files.
This change also moves the __get_tls.h header file to tls.h and includes
the tls defines header so that there is a single header that platform
code can use to get __get_tls and the defines.
Also, simplify the visibility rules for platform includes.
Bug: 141560639
Test: Builds and bionic unit tests pass.
Change-Id: I9e5e9c33fe8a85260f69823468bc9d340ab7a1f9
Merged-In: I9e5e9c33fe8a85260f69823468bc9d340ab7a1f9
(cherry picked from commit 44631c919a)
A kernel update broke three clock_getres tests, so disable
them while the kernel is fixed.
Bug: 141515847
Test: All tests pass on cuttlefish.
Change-Id: I7db789b2b8ba0bc5f8b13bb06e85711031735925
This was necessary because we weren't doing -Werror=fortify-source
everywhere. As of I2715ea411ef067f801534dab4d306fef5431f290, we should
be doing this.
Bug: 131861088
Test: mma
Change-Id: I00d499938ae24c3870760470576d6be603fbecd1
Clang recently grew its own diagnostics for memcpy and such. These are
generally higher-quality than what we can do with diagnose_if, since
clang is happy to include e.g., sizes of things per-callsite. Move to
those instead where applicable.
Bug: 131861088, 123644155
Test: blueline internal-master checkbuild; treehugger
Change-Id: I701f5a8b247ba2948ca47fdc60ff5198b564c03e
Instead of having platform directories directly include the
private header, create a platform header directory and export it.
Bug: 130763340
Test: Builds.
Change-Id: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
Merged-In: Ie0f092b3fe077a3de8b90266c0b28bfbc20d0dfa
(cherry picked from commit 8f582ef2f8)
Add a test for the new flag and add a test for the EFD_CLOEXEC flag.
Test: New unit tests pass on glibc and target.
Change-Id: Ib7a6ea4aadbd67ba8a523b6114a49fb8d6a43f12
This avoids issues where an allocation could create a map while trying
to check data from the maps and running malloc_iterate.
Bug: 137795072
Test: Runs in unit tests.
Change-Id: If8509845d86dd9d002aeac3aa9278fbcf026af17
Previously, Bionic's dl_phdr_info only included the first four
dl_iterate_phdr fields. Several other libc's have these additional fields:
unsigned long long dlpi_adds -- incremented when a library is loaded
unsigned long long dlpi_subs -- incremented when a library is unloaded
size_t dlpi_tls_modid -- TLS module ID
void* dlpi_tls_data -- pointer to current thread's TLS block or NULL
These extra fields are also exposed by glibc, musl, and FreeBSD. The
unwinder in libgcc.a, linked into shipping Android DSOs, has a
PC->eh_frame cache that activates if dl_phdr_info has the dlpi_adds and
dlpi_subs fields (indicated at run-time by a sufficiently-large size
argument to the callback).
Bug: https://github.com/android-ndk/ndk/issues/1062
Test: bionic unit tests
Change-Id: I6f0bab548cf8c828af2ddab9eb01c5c6d70cd81f
The test starts failing in the upcoming lld update. The root cause is
that no relro section is specified by the linker script, and the orphan
placement algorithm decides to place them after .text which is a
misaligned place.
Test: bionic-unit-tests
Bug: 139089152
Bug: 131328001
Change-Id: I2140d8a9fd7c712f1d31a541a3b4a10788385e98
The call to the load hook needs to be moved before the call to link_image()
because the latter calls ifunc resolvers which might access global
variables. This fixes a bunch of ifunc tests.
The dlfcn.segment_gap test is currently failing. One problem is that the name
of the .bss.end_of_gap section changes as a result of global instrumentation.
Add some wildcards in so that we match both names. The other problem seems
to be the same as b/139089152.
It turns out that we need to untag pointers in a few more places. Since we have
quite a few of these now it seems worth creating a function for it.
Test: bionic-unit-tests
Change-Id: I44e2b0904faacdda7cc0c5e844ffc09de01dea2d
Host includes are updated now, so we always must include
bits/stdatomic.h
Bug: 137876753
Bug: 138701943
Test: not yet
Change-Id: Ib2ce34ae5dace8f9a114fa8c04f864cd7f41a5d9
If one of our threads exits and a new process shows up with the same
tid, we would previously loop until that process exits, leading to
flakiness in tests.
Also fix use of uninitialized memory that happens when threads_count !=
kThreadCount.
Bug: http://b/139315254
Test: /data/nativetest/bionic-unit-tests/bionic-unit-tests --gtest_filter="pthread_leak.detach" on cuttlefish
Change-Id: I2aad7f3f105aeba87c3929bfce53ef08e1484b2d
These are old enough now that the latest devices will have kernels that
support them.
Also add basic doc comments to <sys/mman.h>.
Test: treehugger
Change-Id: I1b5ff5db0b6270f5c374287cac1d6a751a0259f5
https://reviews.llvm.org/D58797 added several new compile time
_FORTIFY_SOURCE diagnostics. This broke clang_fortify_tests:
FAILED: out/target/product/walleye/obj/STATIC_LIBRARIES/bionic-compile-time-tests2-clang++_intermediates/clang_fortify_tests.o
error: 'warning' diagnostics seen but not expected:
Line 159: 'memcpy' will always overflow; destination buffer has size 8, but size argument is 9
Line 161: 'memmove' will always overflow; destination buffer has size 8, but size argument is 9
Line 165: 'memset' will always overflow; destination buffer has size 8, but size argument is 9
Line 183: 'strncpy' size argument is too large; destination buffer has size 8, but size argument is 9
Line 185: 'stpncpy' size argument is too large; destination buffer has size 8, but size argument is 9
Line 189: 'strncat' size argument is too large; destination buffer has size 8, but size argument is 9
Line 227: 'strncpy' size argument is too large; destination buffer has size 4, but size argument is 5
Line 232: 'stpncpy' size argument is too large; destination buffer has size 4, but size argument is 5
Line 242: 'strncat' size argument is too large; destination buffer has size 4, but size argument is 5
Line 490: 'snprintf' size argument is too large; destination buffer has size 8, but size argument is 9
Line 495: 'vsnprintf' size argument is too large; destination buffer has size 8, but size argument is 9
error: 'note' diagnostics seen but not expected:
File bionic/libc/include/bits/fortify/fcntl.h Line 50: 'open' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/fcntl.h Line 102: 'open64' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/fcntl.h Line 75: 'openat' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/fcntl.h Line 121: 'openat64' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/stdio.h Line 68: 'sprintf' has been explicitly marked unavailable here
16 errors generated.
Bug: 131328001
Bug: 138701853
Test: Build with r365631 toolchain
Change-Id: I103ecb7b3abcf4b5cfc4f36ccab69e03d0976275
The previous check was causing some problems with platform builds
using the NDK. The new check is more accurate.
Move the C definitions from stdatomic.h to bits/stdatomic.h since
with the new check, we no longer can use the #undef trick to test
them.
Test: build platform NDK with stdatomic.h in pthread.h header
Test: stdatomic bionic-unit-tests
Change-Id: Ia0bc3cc8344f2ba4e6e55a52248fb6efee799d1d
A bit of over-reliance on implementing pthread_cond_clockwait() in
terms of existing functions ended up with a bug that if the condition
variable was initialized to use CLOCK_MONOTONIC, then
pthread_cond_clockwait() would do the wrong thing.
This change corrects that and adds a test for this case.
Test: new and existing tests pthread_cond unit tests
Change-Id: I708d5dfbef95a67678db56dceda011f2f8fd1c5c
Note that unlike the oem_ range that is used for the vendor
partitions, we do not create oem_<n> entries for these new reserved
ranges; they will only appear in getpwent()/getgrent() if there is an
entry in the corresponding passwd/group file.
Bug: 73062966
Test: can load AIDs from partitions other than vendor
Test: bionic-unit-tests
Change-Id: Ifcbbf202894adff948eaaba2a59e25c993611140
This might let us get to using toybox grep for the build faster than if
we have to implement PCRE support.
Test: builds
Change-Id: Idaf24cfefbf18fdc442871f24fe4fe9b2152359a
__builtin_*_chk will emit warnings when things are trivially broken.
Emitting errors instead is probably better (and we can be a bit smarter
about how we emit code for trivially safe cases.)
Bug: 131861088
Test: checkbuild + bionic-unit-tests on blueline
Change-Id: I33957ad419922d0760304758ecb9bc8ad33e0b64
In order for cts to enumerate tests, even tests that are not supported
need to run and be skipped. Make this true for pvalloc/valloc
tests.
Change-Id: I863a179ee6810824a7117f44cc9aa3f86d01eb5b
Test: Ran tests in 32 bit and 64 bit and verified tests are skipped in
Test: 64 bit and run properly in 32 bit.
This also adds _2-variants for these functions, for extra glorious
checking
Bug: 131861088
Test: mma
Change-Id: I80475ff4bb220c0c47894e9532426f53412f176f
We should only be calling _real versions of the functions that use this
if the input size is verifiably <= SSIZE_MAX. Otherwise, just fall
through to _chk and let that handle it.
Bug: 131861088
Test: mma && bionic-unit-tests
Change-Id: Iba04e486ef91ea1b3539ab6df6260429264e66b4
As it says on the box.
Since realpath isn't a function definition, any attributes it provides
here just add to the "regular" realpath.
__wur is being added to realpath because it returns NULL on failure, and
the contents of the input buffer are undefined in that case. A blueline
checkbuild showed 0 complaints about this new __wur, so it seems
harmless to add.
Bug: 131861088
Test: mma
Change-Id: If5f47e0e290d86df69c0888711e29775c390fca4
This CL allows us to diagnose string functions that get an explicit size
passed into them, and string functions that are trivially misused.
Bug: 131861088
Test: mma
Change-Id: I894aec99420a75c6474cfd7d5010f0cf2f10ab21
My declval hack failed on x86_64 with:
```
substitution failure [with T = __va_list_tag [1]]: function cannot
return array type '__va_list_tag [1]'
```
...Because the type of va_list is compiler magic, it's fine for it to be
whatever the compiler wants it to be. Thankfully, pointers to arrays can
be returned, so let's use those instead.
Bug: 135210098
Test: mma on aosp_blueline-eng and aosp_x86_64-eng; the latter was
failing before this patch.
Change-Id: Iefd57c0f8e823653fd70633fb6ee75cfc0022430
Chrome OS has a fairly extensive FORTIFY test suite for both
compile-time and run-time diagnostics. It covers tons of edge cases, and
conveniently centralizes diagnostic and death testing.
A fair amount of it has been ifdef'ed out, since Bionic doesn't yet
diagnose (or crash on) some of these things. The intent is to explicitly
declare defeat on the things we don't care to FORTIFY, and slowly fix
the rest in easier-to-digest CLs.
Once that's done, we might be able to look into retiring some of the
FORTIFY testing that we don't share with the CrOS folks.
Bug: 131861088
Test: mma + bionic-unit-tests on blueline
Change-Id: I16734ea0769e03cf658ef10532d64f28fdb36a89
Cleanup of references to 'coverage' in build files. Part of a larger
cleanup to make fuzzing work again in the Android build tree.
Also fixed a test issue with emulated TLS with the new changes, and
removed libc.so fuzzer support until a linked bug is fixed
(b/132640749).
Bug: 121042685
Test: With all patches in the bug merged: mmma bionic
Change-Id: I592352fe9210ff811a2660a88cbbfe48d70a1e57
Merged-In: I592352fe9210ff811a2660a88cbbfe48d70a1e57
In an attempt to make bionic's reporting of users and groups more
accurate, this change makes the user / group functions do the
following:
1) Fail to query a uid/gid for a secondary user when the uid/gid
doesn't exist. Currently bionic would return successfully but with
a empty string for the name.
2) Fail to query a platform uid/gid, except a limited pre-allocated
set for a secondary user, as these are not used by second users.
3) Fail to query uids for all users for the GID-only app ranges:
CACHE_GID, EXT_GID, EXT_CACHE_GID, SHARED_GID.
4) Fail to query gids in SHARED_GID range for secondary users, as
these GIDs are only allocated for the first user.
5) Use "u#_a#_ext" and u#_a#_ext_cache" for EXT_GID and EXT_CACHE_GID
ranges. This both allows querying based on these names and
returning these names for the appropriate uids/gids.
This also consolidates the tests for better readability.
Test: these unit tests, boot
Change-Id: I59a1af0792e7806d423439582e56ce7f9f801c94
Cleanup of references to 'coverage' in build files. Part of a larger
cleanup to make fuzzing work again in the Android build tree.
Also fixed a test issue with emulated TLS with the new changes, and
removed libc.so fuzzer support until a linked bug is fixed
(b/132640749).
Bug: 121042685
Test: With all patches in the bug merged: mmma bionic
This is the qt-dev-plus-aosp cherrypick of aosp/954684. See the AOSP
commit for further information.
Change-Id: I592352fe9210ff811a2660a88cbbfe48d70a1e57
On cf_x86_phone-userdebug, both of the unwind through signal
tests fail. This has been failing forever, but seems to have suddenly
become an issue, so disable while I try to figure out why this is happening.
Bug: 132763120
Test: Ran on emulator and verified tests are skipped.
Change-Id: Iafc227d972a7783e94c701d73078c9570cea288e
Merged-In: Iafc227d972a7783e94c701d73078c9570cea288e
(cherry picked from commit d424fafbce)
(cherry picked from commit fe0fbcff7f)
A proposed set of changes:
https://android-review.googlesource.com/q/topic:"no-dup-hwasans"
will cause the HWASAN runtime to be moved from /system/lib64 to
/system/lib64/bootstrap. This causes a problem in the case where libc is built
with HWASAN but init is not built with HWASAN. In this case, libc.so will have
a DT_NEEDED dependency on the HWASAN runtime but init will not. Currently,
init and other bootstrap executables arrange to load bootstrap libraries by
setting rpath, but rpath only has an effect on libraries directly depended
on by the main executable, not libraries indirectly depended on by it. This
means that the loading of the HWASAN runtime will fail.
Instead of relying on rpath to find the bootstrap libraries, modify the
bootstrap linker so that it searches the bootstrap library directory after
searching the rpath.
Change-Id: I297be32e04ecd316ee12b8e694588e1249e2bb89
On cf_x86_phone-userdebug, both of the unwind through signal
tests fail. This has been failing forever, but seems to have suddenly
become an issue, so disable while I try to figure out why this is happening.
Bug: 132763120
Test: Ran on emulator and verified tests are skipped.
Change-Id: Iafc227d972a7783e94c701d73078c9570cea288e
Merged-In: Iafc227d972a7783e94c701d73078c9570cea288e
(cherry picked from commit d424fafbce)
getpwnam_r() and getpwuid_r() clobber the storage used by getpwnam()
and getpwuid(). This isn't likely to be a big issue, but since we do
this right for the group functions, fix this as well as add a test.
Both use more space in buf than is actually required, but well below
their sysconf() suggested values, so we accept that to keep the code
concise.
Add tests for dealing with unaligned input buffers, particularly for
getgrnam_r() and getgrgid_r(), as they require alignment but this
wasn't being tested.
Refactor common initialization code for both passwd and group state
structs.
Remove extraneous null pointer checks; the values they were testing
were offsets of a previous pointer, so guaranteed to never actually be
null. If the underlying pointer is actually null, we're beyond repair
anyway, so accept that we'll crash.
Test: pwd/grp unit tests
Change-Id: I60c4d00e9ab3cf55daf8314c5029fd914025b696
This patch decreases created threads to 90 (instead of 100)
on devices with 2 cores CPU. This test can fail with timeout
on such devices.
Bug: b/129924384
Test: Run CtsBionic module on 2 core device with command
"run cts -m CtsBionicTestCases"
Change-Id: Ic770006a324748d7d6dfbe8d4fb301e21e494ff9
Signed-off-by: Dmytro Chystiakov <dmytro.chystiakov@intel.com>
Without pulling in <linux/fs.h>, the UAPI source of these constants,
because it's full of pollution, in particular a macro called BLOCK_SIZE
that breaks a lot of stuff.
Test: treehugger
Change-Id: I7258ec57e91c67645c2b4d0ce44850d757c4bb12
The locking can fail in a couple of ways:
- A concurrent fread from an unbuffered or line-buffered file flushes
the output of other line-buffered files, and if _fwalk locks every
file, then the fread blocks until other file reads have completed.
- __sfp can initialize a file lock while _fwalk is locking/unlocking it.
For now, revert to the behavior Bionic had in previous releases. This
commit reverts the file locking parts of commit
468efc80da.
Bug: http://b/131251441
Bug: http://b/130189834
Test: bionic unit tests
Change-Id: I9e20b9cd8ccd14e7962f7308e174f08af72b56c6
(cherry picked from commit c485cdb024)
Clang uses this for its own diagnostic tests. The nice feature it adds
here is that it fails if clang emits a diagnostic that we don't expect
(and we get to drop a dependency on FileCheck).
This also tweaks and renames file-check-cxx to reflect its new job.
Bug: 131861088
Test: mma
Change-Id: I77f7ce77869edaa23e2401e622ad7007d2fee06c
The locking can fail in a couple of ways:
- A concurrent fread from an unbuffered or line-buffered file flushes
the output of other line-buffered files, and if _fwalk locks every
file, then the fread blocks until other file reads have completed.
- __sfp can initialize a file lock while _fwalk is locking/unlocking it.
For now, revert to the behavior Bionic had in previous releases. This
commit reverts the file locking parts of commit
468efc80da.
Bug: http://b/131251441
Bug: http://b/130189834
Test: bionic unit tests
Change-Id: I9e20b9cd8ccd14e7962f7308e174f08af72b56c6
Also change the names of some of the functions to make it very obvious
that the functions being called are in je code.
Write new test to make sure mallinfo and malloc_info match.
Bug: 131864803
Test: New unit tests pass (along with all other bionic unit tests).
Change-Id: I26eda7e64f57a8c56cc8d70e3ed6a29dcb87f630
Merged-In: I26eda7e64f57a8c56cc8d70e3ed6a29dcb87f630
(cherry picked from commit 125d32cb46)
Also change the names of some of the functions to make it very obvious
that the functions being called are in je code.
Write new test to make sure mallinfo and malloc_info match.
Bug: 131864803
Test: New unit tests pass (along with all other bionic unit tests).
Change-Id: I26eda7e64f57a8c56cc8d70e3ed6a29dcb87f630
This was broken by all the mainline modules stuff. It's quite a bit
hairier to set up now, given that we don't have an apexd on the host.
An alternative might be to actually set up a fake /apex that points to
the bootstrap directories?
Test: ./benchmarks/run-on-host.sh 64
Test: ./tests/run-on-host.sh 64
Change-Id: If2c277ba492c7c443cdf51526ea42f56568e2ea6
FreeBSD, glibc, and musl have all implemented C11 threads at this
point. POSIX is looking at how to align with it. Probably time to jump
on the bandwagon ourselves...
Implemented in the same style as <termios.h> so we can provide this
functionality even on older API levels. This does mean that this is
strictly more expensive than calling pthread functions directly.
Although this isn't in POSIX yet, assume that it's going to be basically
the same as C11 and add the header test anyway. We should revisit this
when POSIX actually adds <threads.h>.
Test: new tests
Change-Id: I8602d67ce71ca7f8ed1529daa0a8ea1feb083dd6
ANDROID_DLEXT_WRITE_RELRO was inadvertently writing out the RELRO
section of all libraries loaded during a given dlopen() call instead of
only the main library; since the other libraries are loaded at
unpredictable addresses this additional data is rarely useful.
Fix this to only happen when the
ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE flag is being used.
Bug: 128623590
Test: DlExtRelroSharingTest.CheckRelroSizes
Change-Id: I05e8651d06ce2de77b8c85fe2b6238f9c09691ad
(cherry picked from commit 5d10374947)
For a recursive or errorcheck PI mutex, the old_owner variable wasn't
being initialized. As a result, unlocking a doubly-locked recursive
mutex owned by another thread decremented the mutex counter. Instead, the
unlock call should fail with EPERM.
Bug: http://b/130841532
Test: bionic-unit-tests
Test: bionic-unit-tests-glibc --gtest_filter='pthread.pthread_mutex_lock*'
Change-Id: I37adb094cb2ce8d51df7b4f48e8d6bc144436418
(cherry picked from commit 4b6c0f5dce)
For a recursive or errorcheck PI mutex, the old_owner variable wasn't
being initialized. As a result, unlocking a doubly-locked recursive
mutex owned by another thread decremented the mutex counter. Instead, the
unlock call should fail with EPERM.
Bug: http://b/130841532
Test: bionic-unit-tests
Test: bionic-unit-tests-glibc --gtest_filter='pthread.pthread_mutex_lock*'
Change-Id: I37adb094cb2ce8d51df7b4f48e8d6bc144436418
ANDROID_DLEXT_WRITE_RELRO was inadvertently writing out the RELRO
section of all libraries loaded during a given dlopen() call instead of
only the main library; since the other libraries are loaded at
unpredictable addresses this additional data is rarely useful.
Fix this to only happen when the
ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE flag is being used.
Bug: 128623590
Test: DlExtRelroSharingTest.CheckRelroSizes
Change-Id: I05e8651d06ce2de77b8c85fe2b6238f9c09691ad
Bug: http://b/129728267
Bug: http://b/117167374
This test is now built with XOM (because libm now uses XOM) but it
should also use libclang_rt.builtins since libgcc is not built with XOM.
Test: bionic-unit-tests-static passes (but used to segfault with XOM
exceptions without this change).
Change-Id: I0b1dfe52e48db5f5e9386c7722ecd91e155be56f
ANDROID_DLEXT_WRITE_RELRO was causing the GNU RELRO sections of
libraries to become corrupted if more than one library was being loaded
at once (i.e. if the root library has DT_NEEDED entries for libraries
that weren't already loaded). The file offset was not being correctly
propagated between calls, so after writing out the (correct) RELRO data
to the file, it was mapping the data at file offset 0 for all libraries,
which corrupted the data for all but one of the libraries.
Fix this by passing file_offset as a pointer the same way that
phdr_table_map_gnu_relro does.
Bug: 128623590
Test: tbd
Change-Id: I196cd336bd5a67454e89fd85487356b1c7856871
The media processes already use scudo as their allocator. However, it
doesn't really correctly replace the normal allocation functions, so create
a set of wrappers that allow us to use scudo closer to how jemalloc is used.
This is only a temporary change, and should be removed for the next
release of Android. In that version, we will be using standalone
scudo which won't require this wrapper code.
Bug: 123689570
Test: Ran new bionic unit tests. There are failures, but only with
Test: extensions that scudo does not support.
Change-Id: I0516c23d654a9b6c69b157c5501245d2e0b3d264
Symbols not intended to be accessible from apps are moved to libdl_android.so
Test: bionic-unit-tests
Bug: http://b/129387775
Change-Id: Ib8ba6147a20cf56550c9a008f66570a2d419565a
(cherry picked from commit 2d6be9a751)
64bit libraries should be located in /system/lib64 directory
instead of /system/lib for platforms with emulated arhitecture.
This patch updated ALTERNATE_PATH_TO_SYSTEM_LIB for 64bit values
Test: run cts -m CtsBionicTestCases -t dlfcn.dladdr_libc
Change-Id: I29d6d36d15d7e61818c7ed1cfd0786745d9ae6a2
Signed-off-by: Dmytro Chystiakov <dmytro.chystiakov@intel.com>
Our strptime was missing `%F`, `%G`, `%g`, `%P`, `%u`, `%V`, and
`%v`. Most of these are already supported upstream (and I've just pulled
their current implementation), but some aren't. We're horribly out of
sync anyway, so I'll upstream the missing pieces and then try to get us
back in sync later.
Test: new tests, but originally found by toybox trying to use %F
Change-Id: Ib1a10801a7a3b9c9189440c3b300109bde535fd9
Subtracting one from the smallest value expressable by the provided
variable could cause an underflow operation. In particular, this is
problematic when code similar to:
uint64_t foo = 0;
if (powerof2(foo)) {
...;
}
is run with integer sanitization enabled. The macro would subtract one
from zero, underflowing and triggering the sanitizer.
Make the powerof2() macro ubsan safe, by explicitly handling underflows.
Note: This change DOES NOT make powerof2() accurate. We continue to
falsely return "true" for 0 and negative numbers (see attached tests).
Found while investigating Bug: 122975762
Test: see added testcase
Test: atest ziparchive-tests
Change-Id: I5408ce5c18868d797bcae8f115ddb7c4c1ced81e
Symbols not intended to be accessible from apps are moved to libdl_android.so
Test: bionic-unit-tests
Change-Id: Ib8ba6147a20cf56550c9a008f66570a2d419565a
Call a hwasan hook in the parent return path for vfork() to let hwasan
update its shadow. See https://github.com/google/sanitizers/issues/925
for more details.
Bug: 112438058
Test: bionic-unit-tests
Change-Id: I9a06800962913e822bd66e072012d0a2c5be453d
Introduce an M_SET_ALLOCATION_LIMIT enumerator for android_mallopt(),
which can be used to set an upper bound on the total size of all
allocations made using the memory allocation APIs.
This is useful for programs such as audioextractor and mediaserver
which need to set such a limit as a security mitigation. Currently
these programs are using setrlimit(RLIMIT_AS) which isn't exactly
what these programs want to control. RLIMIT_AS is also problematic
under sanitizers which allocate large amounts of address space as
shadow memory, and is especially problematic under shadow call stack,
which requires 16MB of address space per thread.
Add new unit tests for bionic.
Add new unit tests for malloc debug that verify that when the limit
is enabled, malloc debug still functions for nearly every allocation
function.
Bug: 118642754
Test: Ran bionic-unit-tests/bionic-unit-tests-static.
Test: Ran malloc debug tests and perfetto integration tests.
Change-Id: I735403c4d2c87f00fb2cdef81d00af0af446b2bb
When built with clang-r353983, the ReservedRecursiveTooSmall test fail
due to the reserved memory is now large enough for android_dlopen_ext.
Reduce the reserved memory size to agree with ReservedTooSmall test.
Test: bionic-unit-tests
Bug: 126457671
Change-Id: I3e311a3f35b0de5d028fa1b9b3681d5ec32faee8
This hasn't been particularly useful, we haven't used it consistently,
and it has caused trouble.
Test: builds
Change-Id: Ic5b5b5124af98aa8301e602fd75b0eb72a5fc7f6
It's possible and sometimes beneficial for a library to have disjoint mappings
and for other libraries to be mapped into the gap between the mappings using
ANDROID_DLEXT_RESERVED_ADDRESS. See for example the proposal for partitioning
in lld [1].
Because the find_containing_library and do_dl_unwind_find_exidx functions use
a simple bounds check to figure out whether a pointer belongs to a library
they will, given a pointer into a library mapped into the gap of a library
with disjoint mappings, return a pointer to the soinfo for the outer library
instead of the inner one, because the outer library will appear before the
inner one in the solist.
From a user perspective this means that we won't be able to unwind the inner
library's frames on 32-bit ARM with libgcc, dladdr() will return information
for the outer library given a pointer to the inner one and dlopen() et al will
use the linker namespace of the outer library when called from the inner one
(although they will usually be the same).
To make this work correctly, make it so that once find_containing_library
sees a match for the bounds check, it examines the library's PT_LOADs to
make sure that there is a mapping for the given address. This is similar
to how libgcc and libunwind_llvm already handle finding the PT_GNU_EH_FRAME
on non-ARM32 platforms [2,3]. do_dl_unwind_find_exidx is reimplemented in
terms of find_containing_library.
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html
[2] e739ac0e25/libunwind/src/AddressSpace.hpp (L523)
[3] https://android.googlesource.com/toolchain/gcc/+/master/gcc-4.9/libgcc/unwind-dw2-fde-dip.c#294
Test: /data/nativetest{,64}/bionic-unit-tests/bionic-unit-tests on walleye-userdebug
Change-Id: I368fe6ad3c470b3dff80f7d9b04253566d63a7d2
malloc_info needs to be per native allocator, but the code treated it
like a global function that doesn't depend on the native memory allocator.
Update malloc debug to dump the actual pointers that it has been tracking.
Test: bionic-unit-tests pass.
Test: malloc debug tests pass.
Test: malloc hook tests pass.
Change-Id: I3b0d4d748489dd84c16d16933479dc8b8d79013e
Merged-In: I3b0d4d748489dd84c16d16933479dc8b8d79013e
(cherry picked from commit a3656a98b1)
bionic has been moved to use libandroidicu instead of libicuuc.
This CL updates the unit test
Bug: 120659668
Test: m bionic-unit-tests && adb push out/target/product/walleye/data/nativetest/* /data/nativetest && adb shell /data/nativetest/bionic-unit-tests/bionic-unit-tests
Change-Id: I59a0589d18bfd6753215dc07874f3c472bd64cca
malloc_info needs to be per native allocator, but the code treated it
like a global function that doesn't depend on the native memory allocator.
Update malloc debug to dump the actual pointers that it has been tracking.
Test: bionic-unit-tests pass.
Test: malloc debug tests pass.
Test: malloc hook tests pass.
Change-Id: I3b0d4d748489dd84c16d16933479dc8b8d79013e
Jemalloc does not verify that the size parameter is a multiple of
alignment. Fix this since it only went into P.
Fix the unit tests, and fix malloc debug/malloc hooks to handle this
new restrictive behavior.
Bug: 126944692
Test: Ran bionic unit tests.
Test: Ran bionic unit tests with malloc hooks enabled (no new tests fail).
Test: Ran bionic unit tests with malloc debug enabled (no new tests fail).
Test: Ran malloc debug unit tests.
Change-Id: I4d50785928815679c781ca729f998454d76b9192
Introduce a new flag ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE which
instructs the linker to use the reserved address space to load all of
the newly-loaded libraries required by a dlopen() call instead of only
the main library. They will be loaded consecutively into that region if
they fit. The RELRO sections of all the loaded libraries will also be
considered for reading/writing shared RELRO data.
This will allow the WebView implementation to potentially consist of
more than one .so file while still benefiting from the RELRO sharing
optimisation, which would otherwise only apply to the "root" .so file.
Test: bionic-unit-tests (existing and newly added)
Bug: 110790153
Change-Id: I61da775c29fd5017d9a1e2b6b3757c3d20a355b3
We still don't have a good way to create vendor AIDs in the system or
other non-vendor partitions, therefore we keep this check disabled.
Bug: 73062966
Test: treehugger
Change-Id: I7aed425899d6ec11a22702ccec82476eacdbc790
The pieces:
- The malloc common shared by static and dynamic code (malloc_common.cpp).
- The code for shared libraries that includes any dlopen'ing
(malloc_common_dynamic.cpp).
- The implementation of perfetto's heapprofd (malloc_heapprofd.cpp).
This makes it easier to see what's going on in the many different areas.
It should also make it easier to add the allocation capping option.
Other related changes:
- Update the unit tests for android_mallopt. All of the current options
don't work on static binaries, so make sure that is reflected in the test.
- A few names changes to make sure that all code is consistent.
Test: Ran tests (malloc hooks/malloc debug/perfetto/bionic unit tests).
Change-Id: I0893bfbc0f83d82506fac5d1f37cf92fbdef6f59
Rename a test to be less confusing when this file tests unresolved weaks
with both TPREL and TLSDESC relocations.
Bug: http://b/123635978
Test: bionic unit tests
Change-Id: Id17d76a41159d134d16e84a699cc284662eb99bb
The test was really only supposed to verify that mallinfo eventually
increase after allocations of certain sizes. Sometimes the mallinfo
returned decreases due to some compaction event, so don't fail in that
case.
Bug: 124060188
Test: Ran the test 2000 times (32 bit and 64 bit). It would fail within about
Test: 200 test iterations before.
Change-Id: Ie019107be163dcf275cedf4d1bc5759278def483
