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
The tzdata file is being removed from the runtime mainline module
in an upcoming commit. This commit removes the bionic references
to it.
This commit also contains general comment tidy-ups.
Bug: 132168458
Test: build only
Change-Id: I83cd9ff756b36e1d1222b7830f97c8bde2885ce4
Historical research (see bug) suggests that these functions were all in
22. The map file believed this with one (presumably typoed) exception,
but the header file didn't match the map file. It looks like the map was
correct (modulo the one typo), so fix up all the disagreement.
Bug: http://b/113618851
Test: treehugger
Change-Id: Ia579f4e6163206abfac79aa54dc98c792f00ee86
We're not going to change this code, ARM's not going to break it.
Silence the warnings.
Bug: http://b/114120867
Test: treehugger
Change-Id: Ie25ef44706c952efc5d54012391bee19af095818
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
This converts all of stdio to short-circuit _chk functions in trivially
safe cases.
Bug: 131861088
Test: checkbuild on internal master. blueline bionic tests pass + it
boots.
Change-Id: I981ac9bd19112492d5a47dc5277526426b9af710
This also lets us retire our |__enable_if| version of |strlen|, which
should catch strictly fewer cases where we can fold the string's length
to a constant than |__builtin_constant_p| inside of |strlen|.
Bug: 131861088
Test: checkbuild on internal master. blueline bionic tests pass + it
boots.
Change-Id: I21b750a24f7d1825591a88d12a385be03a0a7ca3
Android's current lld build has a hack that overaligns TLS segments, but
it broke glibc when it produced TLS segments where (p_vaddr % p_align) was
non-zero. Move the hack into Bionic's crtbegin instead. It will emit a
0-sized, 64-byte alignment TLS segment into executables that don't use
TLS, but that should be harmless.
This variant of the hack is compatible with the gold and lld linkers. The
ld.bfd linker will optimize the .tdata output section out if its size is
zero, preventing the overalignment in an executable that only has .tbss
sections. This problem could be fixed by adding a ". = .;" statement
inside .tdata in ld.bfd's linker script.
See discussion on https://reviews.llvm.org/D61824.
Bug: https://bugs.llvm.org/show_bug.cgi?id=41527
Test: bionic unit tests, boot a device
Change-Id: I34df8b5594b6518d4590e4861e3d0b74d6fa754e
|__builtin_constant_p| has become more flexible in clang. In particular,
it's no longer forcibly lowered before inlining, so we can actually use
it on function parameters (or |__bos(param)|).
This CL tweaks things so that trivially safe calls to FORTIFY'ed
functions compile into direct calls to those functions, rather than to
their _chk counterparts. This will be the most impactful with things
like |memset|, |memcpy|, etc., since clang has way more flexibility
about how to lower those than it does with |__memset_chk|,
|__memcpy_chk|, ...
As noted in the comments, the spelling of the new macros is meant to
match closely with the spelling of our |__bos_static| macros used in
|diagnose_if|.
This isn't a full cleanup of all of the cases in which we can do this.
Just a start on the super simple cases.
Bug: 131861088
Test: m checkbuild; blueline boots.
Change-Id: I696f42ce4a65231e0c4a78a4c5133a6be1cb7708
These were originally #defined so we could share them between our
GCC and clang FORTIFY implementations. Since we no longer have a GCC
FORTIFY, #defining them is sort of pointless.
Bug: 131861088
Test: mma
Change-Id: I2ae4e0bdebbed16c946f5df7cc38c471881b481e
Our diagnose_if conditions are repetitive. It's potentially convenient
to hide that behind a macro. There's an upcoming refactor to our
run-time checks; having static checks look super similar is convenient,
and makes correctness (hopefully) slightly more obvious.
Bug: 131861088
Test: checkbuild on internal master.
Change-Id: Ic39a3b6bf020734c1bef6be144f61ef81466aafe
Bug: 123312263
Test: Verified with asan enabled, malloc debug does not initialize.
Test: Ran tests on non-asan build and verify they pass.
Change-Id: I3c37c170bf6c1de42740972f2113ae991351d931
The arm exidx unwind information can be sparse and clang is producing
functions that cannot be properly represented. The .debug_frame includes
extra unwind information that covers the cases that are not complete, so
do not remove it. For example, the __strchr_chk function has a push
in the middle of the function, so any crash before that instruction will
not unwind properly.
This does increase the size of libc.so, but only by about 80,000 bytes.
Bug: 132992102
Test: Verified the .debug_frame exists in libc.so only for arm32.
Test: Used the unwind_reg_info to verify that __str_chk gets proper
Test: unwind info. Also use unwind_reg_info on some assembler functions
Test: to make sure that there is no overlapping information.
Change-Id: If9a6de15b3adf08a93c4563da8c89846e4dd059b
Add the malloc symbols used by libmemunreachable to the VNDK, and
make libc_malloc_debug_backtrace vendor_available.
Bug: 132302484
Test: m checkbuild
Change-Id: Ide555195afa084c13eaeaf0eab6ff90787b5f2d0
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
When building the bionic tests, we use -fno-builtins, which turns off
clang's recognition of vfork as a magical function that can return
twice. Explicitly annotate our returns_twice functions to ensure that
we generate correct code even in -fno-builtins (and while we're at it,
annotate the no_return functions as well, so we generate faster code).
Bug: http://b/131856005
Test: treehugger
Change-Id: I465f8042a965f0c7c03caa5f17af67deea8f5d9d
Added get_malloc_leak_info and free_malloc_leak_info for arm 32 bit
only so that the kindle app will continue to run.
Bug: 132175052
Test: Ran kindle app, read pdf file. Verified libKindleReaderJNI.so
Test: is loaded in memory properly.
Change-Id: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
Merged-In: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
(cherry picked from commit 235f35a266)
I wrote a new unit test that would fail on the old version of the
code.
On a walleye big cpu, this costs about 40ns-50ns (going from ~430ns to ~480ns).
I think this is an acceptable performance degradation.
Bug: 131867816
Test: New unit tests pass.
Change-Id: I4c0f4373fb0694bf29c3824dbb1224a8a17e211e
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
Enable native bridge support for bionic libraries.
Makes it possible to use them in binaries for translated
architectures.
Bug: http://b/77159578
Test: make
Change-Id: Iccd4ad7aecfa5260cc15f09ca975d2e18987278a
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)
Bug: 131362671
Test: Ran bionic unit tests.
Test: Wrote a test that did a purge and verified that the tcache->ncached
Test: number went from 3 to 0. Also verified that mallinfo reflects the
Test: cached entries being flushed.
Change-Id: I64e35618fa3b523cf29bdaceedef676abe440dd3
Similar to the way we handle LIBC_DEBUG_MALLOC_OPTIONS
(bug 68003719), filter LIBC_HOOKS_ENABLE when we cross a
security boundary. This prevents modifying the allocation
behavior of a privileged program.
Introduced in
db478a6274%5E%21/#F0
(bug 30561479)
Test: compiles and boots
Change-Id: I59a7c224734b0991fd62efb45ab599dab8570723
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.
Commit 02586a2a34 ("linker: the
global group is added to all built-in namespaces", Aug 2017) added
support for the environment variable LD_CONFIG_FILE. This debug build
only feature allows the caller to specify the path to the loader
configuration file. Like other linker environment variables, setting
this variable allows the calling process to control executed code of the
called process, which has security implications (on debuggable builds
only).
Add LD_CONFIG_FILE to UNSAFE_VARIABLE_NAMES. This has the effect of
stripping, on all build types, the LD_CONFIG_FILE environment variable.
This has three advantages:
1) Prevents security bugs should LD_CONFIG_FILE ever be inadvertantly
exposed on a production build.
2) Makes the behavior of userdebug and user builds more similar, helping
prevent build-type dependent bugs where someone may come to rely on this
debug-only feature.
3) Protect droidfood users against malicious applications which can
trigger a security transition, eg, the execution of crash_dump or the
renderscript compiler.
Alternative considered but rejected:
If we treated LD_CONFIG_FILE like LD_PRELOAD, we could expose this on
all build types, and remove the build-type dependent behavior. But this
is contrary to enh's Aug 02 2017 guidance at
https://android-review.googlesource.com/c/platform/bionic/+/449956
i'm still uncomfortable about LD_CONFIG_FILE because i'd like
to be reducing the number of environment variables that affect
the linker in P rather than increasing them.
Test: atest CtsBionicTestCases
Test: atest linker-unit-tests
Change-Id: I82d286546ee079b5cde04428dc89941c253c2d20
In __cxa_finalize, only call fflush(NULL) when the program is exiting, not
when a library is unloaded with dlclose. This change restores behavior
from 2015.
Flushing output is needed when the program exits, but flushing everything
is hazardous at other times because it can block -- fflush(NULL) locks
every file, so it also blocks on read operations.
Bug: http://b/130655235
Test: manual
Change-Id: I2f5ecffa6724bfd98a93d145ab5313c793c01ae6
Devices launched before Q may be using OEM defined AID that are not in
the OEM_RESERVED ranges. Those devices should be allowed to keep using
legacy oem AID values given it may not be possible to upgrade the
userdata and persist files through OTA.
Bug: 131095318
Test: bionic-unit-tests
Change-Id: I73fc0c452420be5287adcacb36a1e772acc9bb3e
Move /system dependency on tz_version to bionic from core-libart.
The file is not used by code but is useful on device to identify
the format / version / origin of the tzdata file. The
tz_version file identifies the Android release (e.g. 3.1 == Q), which
implies the version of zic used to generate tzdata, and any Android
revision of the tzdata (e.g. 2019a v2) that may have taken place. The
file was previously used by by the tzdatacheck binary but it has since
switched to using the copy in the runtime module.
The bionic README.md is also updated here to reflect latest locations of
scripts.
Bug: 131239046
Test: make installclean / make droid / inspect /system
Change-Id: Ib142f98aa30c8c9d5eda33df55d4191478570ced
We loop through android_ids in many functions, but this can be
consolidated into find functions.
Test: bionic-unit-tests
Change-Id: I70c423affe49090a93e999c72bb4c84a068de5d8
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
These symbols were previously provided by Android's out-dated libgcc,
but they're removed/deprecated in upstream libgcc, and also won't be
available in libclang_rt.builtins. We need to provide these methods in
libc itself for compatiblity.
Test: build with these symbols stripped in libgcc
Bug: 29275768
Change-Id: I04a05258c6c06b5a22ead41e148b02792ffbc941
This reverts commit e4788d4c7e,
which undid this change during the Q betas.
Bug: http://b/120989619
Change-Id: Iea589fd0e56426971adf9f7c19c2aedf0d7a7a60
Ensure we call realloc@plt rather than (as was previously happening)
inlining realloc into reallocarray, which makes the allocation invisible
to ASan.
Bug: http://b/129989984
Test: objdump
Change-Id: If8a43cba11aa5a2f2f62bacd02ef6ef4032e0dbb
Add a couple of comments explaining that a mutex can be freed during
the unlock call, immediately after the unlock's atomic exchange call but
before its futex wakeup call.
Bug: http://b/129744706
Test: bionic unit tests
Change-Id: I2d290ebde880f46866098d022720896039e7022e
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
The libstdc++ directory has no copyright headers, so it was a no-op
anyway.
The interesting part will be switching libc and libm over to genrules...
Test: N/A
Change-Id: Iec92562af40c451fdcb4a7468984878ec5dba2ce
Bug: 130028357
Test: malloc_hooks unit tests.
Test: Enable backtrace for mediaserver, run dumpsys media.player -m
Test: Enable backtrace for calendar, run am dumpheap -n <PID> <FILE>
Change-Id: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
Merged-In: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
(cherry picked from commit 3aadc5e80a)
Remove this global variable and change the setting of it to non-zero
to a call to android_mallopt.
In addition, change the initialize function to use pass a bool* instead of
int*.
Bug: 130028357
Test: Ran malloc_debug/malloc_hooks/perfetto tests.
Change-Id: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
Merged-In: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
(cherry picked from commit 5225b342f0)
...all the better to switch to a genrule rather than checking in
generated source.
This also removes all the code in the script to deal with git,
rather than fix it. We won't need that where we're going.
Test: boots
Change-Id: I468ce019d4232a7ef27e5cb5cfd89f4c2fe4ecbd
Enable the use case where we run clean_header.py from outside of
$ANDROID_BUILD_TOP. Previously, this script required the current working
directory to be under $ANDROID_BUILD_TOP. Running it from a different
directory resulted in the following error message:
clean_header.py: error: Not in android tree pointed at by ANDROID_BUILD_TOP (....)
Change-Id: I48210ea1a0033228a9aaa4124d28247b07cee6d4
The function cleanupFile should always return a single value (as opposed
to a tuple or list). In addition, if it encounters an error, it is
expected to return a value that evaluates to False. As it stands,
however, it returns (None, None) in certain error cases. Change this
function to return None, in those cases.
We previously saw the following error message, when we tried to run
clean_header.py on a non-existent file.
Traceback (most recent call last):
File "clean_header.py", line 208, in <module>
b.updateGitFiles()
File "utils.py", line 164, in updateGitFiles
self._writeFile(dst)
File "utils.py", line 136, in _writeFile
f.write(self.new_data[dst])
TypeError: expected a string or other character buffer object
Change-Id: I5f717dd1a4388f598f0fd4bfd5e6129017de9095
malloc_common_dynamic.cpp is compiled into both libc.so and
libc_scudo.so. When compiled for libc_scudo.so, it doesn't try to load
libc_malloc_* libs from the runtime linker namespace. This is because,
unlike libc.so which is shared from the runtime APEX, libc_scudo.so is
copied to any APEX that it needs. Furthermore, libdl_android which
provides android_get_exported_namespace is not available for vendors. So
the vendor variant of libc_scudo.so can't anyway locate the runtime
namespace.
Bug: 130213757
Bug: 122566199
Test: `m libc_scudo libc_scudo` is successful
Test: inspect the built library to see if it has reference to
android_get_exported_namespace
Merged-In: I4c41de361fdb3fa34b95218923f4ce4e9c010f9e
Change-Id: I4c41de361fdb3fa34b95218923f4ce4e9c010f9e
(cherry picked from commit ff94a13d2d)
/system/lib/libc.so is a symlink to libc.so in the runtime APEX.
libc_malloc_* libraries are bundled with libc.so because they share
implementation details.
However, since libc.so is loaded in the default namespace where the
runtime APEX path (/apex/com.android.runtime/lib) is not accessible,
libc.so has been using libc_malloc_* from /system/lib. This is
wrong because libc.so (from the runtime APEX) and libc_malloc_* (from
the platform) may not be in-sync.
libc.so now uses android_dlopen_ext to load libc_malloc_* libraries
correctly from the "runtime" linker namespace.
Bug: 122566199
Test: bionic-unit-tests
Merged-In: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
Change-Id: I46980fbe89e93ea79a7760c9b8eb007af0ada8d8
(cherry picked from commit 4e46ac69c2)
Issue:
Process is crashed near the end (startup_handshake_lock.unlock()) in
pthread_create().
The newly created child thread passes this handshake_lock unexpectedly
=> its stack is unmapped & its associated pthread_internal_t data
structure can’t be accessed.
Analysis:
The created child thread should be blocked by startup_handshake_lock.lock()
and enter __futex_wait_ex()
But if the parent thread is in the middle of startup_handshake_lock.unlock():
void unlock() {
if (atomic_exchange_explicit(&state, Unlocked, memory_order_seq_cst) == LockedWithWaiter) { // => the state is modified to Unlocked
// (a) if the child thread is back to running and pass the while() check in Lock::lock()
// (b) the child thread executes its start_routine and then pthread_exit
// (c) the stack of the child thread (where its pthread_internal_t (so the startup_handshake_lock) is located) will be unmapped
__futex_wake_ex(&state, process_shared, 1); // => when the parent thread is back to running
// the “state” & “process_shared” of startup_handshake_lock can’t be accessed (unmapped)
// so the process will be crashed
}
}
Bug: 129744706
Test: Monkey
Change-Id: I55175e8c7ebc2b3b52de8a5602def0667076b974
Add a new option verbose for malloc debug that is not enabled by default.
This disables all of the info log messages. It turns out these log
messages can add a measurable amount of time and can change the boot up.
Bug: 129239269
Test: Adjusted unit tests pass.
Test: Verified no messages unless verbose option used.
Change-Id: I805cb7c8ecb44de88119574e59d784877cacc383
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
There have been several changes since the file was created. Update the
file with latest build. We also sort the symbols by names when they
have the same size so that future updates are easier to review.
Bug: 124521408
Test: Build and inspect symbol ordering
Change-Id: Iedd885b9a87d882ae278a1f117f40b20d064c384
Don't print an extraneous newline character at the end of the include
file if clean_header.py is used in the non-update mode. This is
necessary to achieve consistent results in the update and non-update
modes.
Running clean_header in the non-update mode and redirecting the output
to a file should have the same result as using the update mode and have
the script write to the file directly.
Change-Id: I6b176c5365840d66e4499bacd205f1fa77302a2b
Write to correct dst_file when in update mode. This enables use cases
like the following:
../../../bionic/libc/kernel/tools/clean_header.py -k original-kernel-headers/ -d kernel-headers/ -u linux/ion.h
Previously, we had to cd into kernel-headers/ and then run
../../../../bionic/libc/kernel/tools/clean_header.py -k ../original-kernel-headers/ -d . -u linux/ion.h
because the tool didn't allow the relative path to be different from the
destination path.
Change-Id: I8c5e284ce7a6737d77a2f5ead3e7e5db01317425
The previous refactor left a double call to the initialization of
the loaded hooks. Remove the unnecessary call.
Bug: 129239269
Test: All unit tests pass. No double printing of init messages.
Change-Id: Ie980f2383c75d69f8b06bf9a431bb59caef21188
This makes it easier for tools to find the mapping. I am planning
to use this in crashpad to add HWASAN reports to the minidump.
Bug: http://crbug.com/crashpad/287
Change-Id: I600e551ef26d6ff62849319365d77912afa82fde
c50b6a2b89 redefined the powerof2 macro,
but in a way that that didn't meet the clang_format style guidelines.
Change powerof2 to make clang_format happy.
Test: compiles
Change-Id: Icd04a17f40413b7a416ddcdc080edbc4d3fac87a
With __cpu_model visibility issue fixed in libcrt, we can move x86 and
x86_64 libc to use libcrt as well.
Test: emulator boots
Bug: 122993569
Change-Id: If71c324180010a57e3e9598d758a4d6ab1a3c369
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
Bug: http://b/128524141
This signal is used by libprofile-extras to trigger flush of gcov
coverage data.
Test: libprofile-extras in system/extras/toolchain-extras
Change-Id: I77dd5b1d67371a9cfaad54ad60254bfb2dd18ba9
We regressed on this recently: code under the upstream-* directories has
_PATH_BSHELL defined as a call to __bionic_get_shell_path(). In our own
code, we may as well just call it directly.
Bug: https://issuetracker.google.com/129030706
Test: ran tests
Change-Id: Ic2423f521272be95e67f94771772fe8072636ef0
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
We don't need this now that popen always uses O_CLOEXEC, and it's unsafe
because _fwalk takes a lock. (In <= P, the equivalent code walked the
list without a lock in the child.)
Bug: http://b/129156634
Test: ran tests
Change-Id: Ic9cee7eb59cfc9397f370d1dc47ea3d3326179ca
This commit adds missing INTRODUCTED_IN(29) annotations to fdsan.h.
Note: This is not revealed until recently because API level 29 is added
in Mar 14 and the prebuilt binary for versioner hasn't been updated.
Test: ./bionic/tools/versioner/run_tests.py
Change-Id: Ie7bf555bb47c97d15f0c5fa36a76bc6cd64e206b
This commit fixes an inline and non-inline mismatch error caused by
`get_device_api_level_inlines.h`.
Versioner includes both `android/api-level.h` and
`bits/get_device_api_level_inlines.h` in the test. When __ANDROID_API__
is greater than or equal to __ANDROID_API_Q__, `android/api-level.h`
declares a non-inline `android_get_device_api_level()`. On the
contrary, `bits/get_device_api_level_inlines.h` defines a static inline
`android_get_device_api_level()` function. These conflicting
declarations result in compilation error.
This commit fixes the problem by guarding full
`get_device_api_level_inline.h` with
`#if defined(__BIONIC_GET_DEVICE_API_LEVEL_INLINE)` so that
`get_device_api_level_inline.h` can be no-op when it is not properly
included.
Note: This is not revealed until recently because API level 29 is added
in Mar 14 and the prebuilt binary for versioner hasn't been updated.
Test: ./bionic/tools/versioner/run_tests.py
Change-Id: Ia7d5fbdcaf3d98787e60780f6cff2a24016324f5
This commit suppress warnings on pthread_create because clang-r353983
would check the function declaration against the built-in function
defined in llvm/tools/clang/include/clang/Basic/Builtins.def and find a
mismatch.
Note: This is only found by versioner because these files are not system
headers from the perspective of versioner. This warning is ignored in
normal builds because bionic headers are system headers in normal
builds.
Bug: 126457671
Test: lunch walleye-userdebug && make
Change-Id: I3f05ba19861f1b9db55c7c55c4496a845802e831
__hwasan_init() was segfaulting when called from here because it
was calling into libc functions which required more of libc to be
initialized. Instead, call __hwasan_init_static(), which does a
minimal amount of initialization for statically linked executables,
just enough that we can run instrumented code. __hwasan_init() itself
will end up being called later (most likely from a global ctor)
after libc is fully initialized.
We'll need to wait for LLVM r352816+r352823 to land in our toolchain
before landing this.
Change-Id: I12ffc7e08f6dd161e4ff2088f8d56265af7baedf
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
Bug: 128872105
Test: Ran the android_mallopt.set_allocation_limit_multiple_threads test
Test: a thousand times on taimen.
Change-Id: I67a474c53cd6eda8106feac99aee8e7b0bee1254
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
This hasn't been particularly useful, we haven't used it consistently,
and it has caused trouble.
Test: builds
Change-Id: Ic5b5b5124af98aa8301e602fd75b0eb72a5fc7f6
The *.mountpoint targets that installs /bionic/lib/lib*.so and
/bionic/bin/linker* are no longer needed.
Now, /system/lib/lib*.so and /system/bin/linker* are simply symlinks to
the corresponding files in the runtime apex. For example,
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
This is made possible because we now activate APEXes even before the
data partition is mounted. Before the data partition mounting, the
APEXes from the system partition are ativated. After the data partition
is mounted, updated APEXes in the partition (if any) are activated. As a
result, the symlink always points to the valid path regardless of
whether /data is mounted or not.
Bug: 125549215
Test: device boots
Change-Id: Ie7d83686abe00b3c436f9f9db75d4244200a0fc9
To mirror device code more closely, look for time zone data using
ANDROID_TZDATA_ROOT on host. For device usecases the path is still
hardcoded.
Bug: 128422035
Test: build only
Change-Id: I5762745349338bcc3e3a173c1c9b18ea5a3324dd
When we enable free_track option, one thread is in AddFreed->RemoveBacktrace
flow (hold free_pointer_mutex_ first and try to lock frame_mutex_), and
other thread do fork and enter PrepareFork flow (hold frame_mutex_ first
and try to lock free_pointer_mutex_), this situation may result in mutex
deadlock issue.
Bug: 127733115
Test: build pass and stress test pass
Change-Id: Ie5fcc4ef6c169372ad73d81978cfb2a726b6c03e
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)
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
The upcoming compiler warns against adding string and int:
In file included from bionic/libc/bionic/strsignal.cpp:41:
bionic/libc/private/bionic_sigdefs.h:58:1: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int]
__BIONIC_SIGDEF(SIGWINCH, "Window size changed")
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bionic/libc/bionic/strsignal.cpp:40:83: note: expanded from macro '__BIONIC_SIGDEF'
#define __BIONIC_SIGDEF(signal_number, unused) [ signal_number ] = #signal_number + 3,
~~~~~~~~~~~~~~~^~~
Use array indexing index to avoid this warning.
Test: m checkbuild
Change-Id: Ib5e20edbf5bac76352df0484dd233d0621beb4e9
