Coming to C23 via WG14 N2630.
This one is a little interesting, because it actually changes existing
behavior. Previously "0b101" would be parsed as "0", "b", "101" by these
functions. I'm led to believe that glibc plans to actually have separate
versions of these functions for C23 and pre-C23, so callers can have the
behavior they (implicitly) specify by virtue of which -std= they compile
with. Android has never really done anything like that, and I'm pretty
sure app developers have more than enough to worry about with API levels
without having to deal with the cartesian product of API level and C
standard.
Therefore, my plan A is "if you're running on Android >= U, you get C23
behavior". My plan B in the (I think unlikely) event that that actually
causes trouble for anyone is "if you're _targeting_ Android >= U, you
get C23 behavior". I don't think we'd actually want to have two versions
of each of these functions under any circumstances --- that seems by far
the most confusing option.
Test: treehugger
Change-Id: I0bbb30315d3fabd306905ad1484361f5d8745935
Noticed by "NRK": https://www.openwall.com/lists/musl/2022/07/29/5
We don't have this problem elsewhere in bionic because it's so rare to
call getline() without a loop, and the free() is always outside the loop
because that's a handy optimization.
Test: treehugger
Change-Id: Iff8845aa226d87357b38cf4a285fc1be3cac5659
It came up on the musl mailing list that there's not actually any need
to iterate over the directory entries:
https://www.openwall.com/lists/musl/2022/07/27/1
This lets us reuse the code for "online" processors in the
implementation of "configured" processors. The question of whether
"configured" should correspond to Linux's "possible" or "present" isn't
obvious to me, but the distinction seems unlikely to matter on mobile
devices anyway, and that's a trivial change should it ever be needed.
Plus the motivating argument from the person who brought this up was
that callers asking for "configured" processors are probably asking for
an upper bound, which sounds convincing to me.
Test: treehugger
Change-Id: I0d4e13538dc6b09a6dba520d9ac24f436906f7c0
Adds persistent sysprops for test infra usage, and adds the tests for
the sysprops.
The test does some fancy flocking in order to restore any existing
GWP-ASan sysprop usage in the test cleanup.
Bug: 236738714
Test: atest bionic-unit-tests
Change-Id: I8956296d39c98ce8c7dd0a703b240530d8ad48db
This file is included in libandroid_support.a, where using new/delete
breaks libc++ tests that assume that libc++ makes no extraneous
new/delete calls.
This CL changes newlocale/duplocale to return NULL on out-of-memory.
Previously, the behavior varied:
- libc.so: aborted using async_safe_fatal
- libandroid_support.a: throws std::bad_alloc
Bug: none
Test: std/input.output/filesystems/class.path/path.member/path.assign/move.pass.cpp
Test: libcxx/localization/locales/locale/locale.types/locale.facet/no_allocation.pass.cpp
Test: std/input.output/filesystems/class.path/path.member/path.construct/move.pass.cpp
Change-Id: I38c772f249f32322afb9402ebeeb4bb65a908b59
Upstream has renamed tzsetlcl to tzset_unlocked. As bionic's
implementation of tzset_unlock differs from upstream, these changes were
skipped.
Also, upstream has removed constants (SECSPERMIN, etc) from tzfile.h. As
they are used in strptime.c, I've decided to leave them in tzfile.h and
to not bring them into strptime.c.
HAVE_TZNAME and USG_COMPAT flags semantics were updated, thus setting
their values to 2 in Android.bp file. See
1a27ec76bc
* 4742526b7e
and 0e8f0b06ac
were picked up, which are not part of 2022a.
Changes were applied using following commands:
1) Checkout tzcode repo
2) Prepare patches for all tzcode file using
git diff 2016g 2021e -- <file-name> > <file-name-patch>
3) Apply these patches to files in bionic using
patch -p1 <file-name> <file-name-patch>
Bug: 25413083
Test: CtsLibcoreTestCases
Test: CtsLibcoreOjTestCases
Test: CtsBionicTestCases
Change-Id: I9aba4cbeab30171a32f94d20c8e4057804a4c01f
With memtag_stack, each function is responsible for cleaning up
allocation tags for its stack frame. Allocation tags for anything below
SP must match the address tag in SP.
Both vfork and longjmp implement non-local control transfer which
abandons part of the stack without proper cleanup. Update allocation
tags:
* For longjmp, we know both source and destination values of SP.
* For vfork, save the value of SP before exit() or exec*() - the only
valid ways of ending the child process according to POSIX - and reset
tags from there to SP-in-parent.
This is not 100% solid and can be confused by a number of hopefully
uncommon conditions:
* Segmented stacks.
* Longjmp from sigaltstack into the main stack.
* Some kind of userspace thread implementation using longjmp (that's UB,
longjmp can only return to the caller on the current stack).
* and other strange things.
This change adds a sanity limit on the size of the tag cleanup. Also,
this logic is only activated in the binaries that carry the
NT_MEMTAG_STACK note (set by -fsanitize=memtag-stack) which is meant as
a debugging configuration, is not compatible with pre-armv9 CPUs, and
should not be set on production code.
Bug: b/174878242
Test: fvp_mini with ToT LLVM (more test in a separate change)
Change-Id: Ibef8b2fc5a6ce85c8e562dead1019964d9f6b80b
Map all stacks (primary, thread, and sigaltstack) as PROT_MTE when the
binary requests it through the ELF note.
For the reference, the note is produced by the following toolchain changes:
https://reviews.llvm.org/D118948https://reviews.llvm.org/D119384https://reviews.llvm.org/D119381
Bug: b/174878242
Test: fvp_mini with ToT LLVM (more tests in a separate change)
Change-Id: I04a4e21c966e7309b47b1f549a2919958d93a872
See:
https://man7.org/linux/man-pages/man2/close_range.2.html
Note: 'man close_range' documents 'flags' as unsigned int,
while glibc unistd.h as just 'int'. Picking 'int' to match glibc,
though it probably doesn't matter.
BYPASS_INCLUSIVE_LANGUAGE_REASON=man is a cli command
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1e2d1c8edc2ea28922d60f3ce3e534a784622cd1
Linux kernel's close_range() system call (currently) allows:
close() unshare() fcntl(F_SETFD, FD_CLOEXEC)
to be performed on ranges of fds.
All 3 of these are already allowed by seccomp bpf:
as such this doesn't allow you to do anything you can't already do.
We can't add close_range() properly to bionic because we'd need to
fiddle about with ltp and it's too late to add new T API anyway,
so let's just make the direct syscall() call.
We'll add proper support in U.
See also:
https://man7.org/linux/man-pages/man2/close_range.2.html
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I85586d544fc23bed6aee59f00bdb79ee7a8150d1
This new posix_spawn attribute flag marks all file descriptors
(except stdin/out/err) as close-on-exec before executing any user
registered file actions (posix_spawn_file_actions_addopen/adddup2).
Test: TreeHugger
Bug: 229913920
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If458100d6a253a9b0348d4e93a9a610225f89615
This patch introduces GWP-ASan system properties and environment
variables to control the internal sampling rates of GWP-ASan. This can
be used for:
1. "Torture testing" the system, i.e. running it under an extremely
high sampling rate under GWP-ASan.
2. Increasing sampling remotely to allow further crash report
collection of rare issues.
There are three sets of system properites:
1. libc.debug.gwp_asan.*.system_default: Default values for native
executables and system apps.
2. libc.debug.gwp_asan.*.app_default: Default values for non-system
apps, and
3. libc.debug.gwp_asan.*.<basename/app_name>: Default values for an
individual app or native process.
There are three variables that can be changed:
1. The allocation sampling rate (default: 2500) - using the environment
variable GWP_ASAN_SAMPLE_RATE or the libc.debug.gwp_asan.sample_rate.*
system property.
2. The process sampling rate (default: 128 for system apps/processes, 1
for opted-in apps) - using the environment variable
GWP_ASAN_PROCESS_SAMPLING or the libc.debug.gwp_asan.process_sampling.*
system property,
3. The number of slots available (default: 32) - using the environment
variable GWP_ASAN_MAX_ALLOCS or the libc.debug.gwp_asan.max_allocs.*
system property.
If not specified, #3 will be calculated as a ratio of the default
|2500 SampleRate : 32 slots|. So, a sample rate of "1250" (i.e. twice as
frequent sampling) will result in a doubling of the max_allocs to "64".
Bug: 219651032
Test: atest bionic-unit-tests
Change-Id: Idb40a2a4d074e01ce3c4e635ad639a91a32d570f
If a process is failing due to out of memory, some code calls
android_set_abort_message with a nullptr. Specifically, the libc++
library std::terminate can call do this. In this case, put a
null in the abort message.
Test: Call with nullptr and verify the code does not crash.
Test: Modified crasher to set an abort message and set a null abort
Test: message. Ran both, verified the abort message displays in
Test: first case, and doesn't display in the second case.
Change-Id: Ia9250f47e4537853ce93bbb20b35915a78caa502
Two edge cases were found in aosp/2038947:
1. realloc(p, 0) == free() and returns nullptr. Previously, we just
returned a new pointer.
2. If the malloc() part of realloc() fails (e.g. when the size of the
allocation is 1 << 56), then the old memory shouldn't be destroyed.
Bug: N/A
Test: Covered using atest bionic-unit-tests using aosp/2038947.
Change-Id: Ibafc752787129922a1e0323ffa14221d6a14f108
Revert submission 1954983-master-I3030c47be9d02a27505bd4775c1982a20755758c
Reason for revert: PAC has shipped with S, and we're going with app compat outreach rather than regressing security.
Reverted Changes:
I3030c47be:Disable pointer authentication in app processes.
I3030c47be:Disable pointer authentication in app processes.
Change-Id: I8761f08ddbd9077ff98b1a9a0c323de968792778
dup2(2) is a no-op if the new and old fds are equal, but it's pretty
clear that any useful caller in the posix_spawn(3) context wants us to
clear O_CLOEXEC even if we don't actually "move" the fd.
Bug: https://www.austingroupbugs.net/view.php?id=411
Test: treehugger
Change-Id: I5ce1a1f9216df5afd295cc9e35b84527873e9541
For the perf profiling signal handler to succeed in opening
/proc/self/mem, the process needs to be marked as dumpable in posix
terms. This patch addresses a scenario since Android S where the process
is considered profileable, but is not dumpable on "user" builds. The
solution is to mark the process as dumpable while opening the procfs
descriptors, restoring the original value afterwards. This is the same
approach as the heapprofd heap profiler, which performs the override
within the loaded client library [1].
The particular scenario being addressed is:
* user build
* app does not explicitly opt into being profiled by shell
* app does not explicitly opt out of all profiling
In this case, the app is considered profileable by the platform (but NOT
shell). Therefore ActivityThread marks the process as profileable [2],
but the zygote keeps the process as undumpable as it considers the
profileability from the shell domain [3]. We could change the logic in
the zygote to leave such processes in the dumpable state, but the
override within the signal handler is considered to be more contained as
the dumpability is only needed temporarily.
This override would also apply for any non-dumpable native services that
are signalled for profiling, which is also desireable for profiling
coverage.
This change does not elide any of the existing profileability
checks by the signal handler's preamble and the profiler itself.
[1]
https://cs.android.com/android/platform/superproject/+/master:external/perfetto/src/profiling/memory/client.cc;l=184;drc=78cd82ba31233ce810618e07d349fd34efdb861d
[2]
https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/ActivityThread.java;l=6610;drc=de9cf3392d7872c2bee69b65a614e77bb166b26e
[3]
https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/jni/com_android_internal_os_Zygote.cpp;l=1680;drc=master
Tested: clock app on barbet-user succeeds in opening the procfs
descriptors within the signal handler.
Tested: systemwide profiling on sargo-userdebug works as before.
Bug: 196810669
BYPASS_INCLUSIVE_LANGUAGE_REASON=referencing the name of a cmdline utility
Change-Id: Id621d4312418ff0736c97065e9ee577ff67f40da
Currently, the ELF note parsing in the loader is not permissive. This
patch relaxes the restrictions on the bits of the ELF note that could be
extended in the future.
This may allow more MTE options in apexes. If we add some extra metadata
bit (say, in bit 5) in the future, and then build MTE into every apex,
we don't want it to crash on Android 13 devices (we'd much rather it
just be a no-op).
Remove the (unused anywhere) NT_MEMTAG_DEFAULT and call it
NT_MEMTAG_NONE.
And finally, make the tests work on bionic-unit-tests-static. We
previously didn't deploy the test binaries, so add them as a data
dependency.
Bug: N/A
Test: atest bionic-unit-tests-static
Change-Id: I13530faad55c719c6eb848297f8ce378e18afbfc
Normally, platform-specific note types in the toolchain are prefixed
with the platform name. Because we're exposing the NT_TYPE_MEMTAG and
synthesizing the note in the toolchain in an upcoming patch
(https://reviews.llvm.org/D118948), it's been requested that we change
the name to include the platform prefix.
While NT_TYPE_IDENT and NT_TYPE_KUSER aren't known about or synthesized
by the toolchain, update those references as well for consistency.
Bug: N/A
Test: Build Android
Change-Id: I7742e4917ae275d59d7984991664ea48028053a1
The first time should_trace() returns true, bionic_trace_begin() calls
open() on trace_marker.
The problem is that open() can call bionic_trace_begin(). We've observed
this happening, for example when:
* fdtrack is enabled. dlopen("libfdtrack.so") can be used to enable
fdtrack on a process.
* ThreadA is busy unwinding inside fdtrack and is holding an fdtrack
internal mutex.
* ThreadB calls bionic_trace_begin() for the first time since the
property "debug.atrace.tags.enableflags" contains ATRACE_TAG_BIONIC.
* ThreadB calls open("/sys/kernel/tracing/trace_marker"). Since fdtrack
is enabled, ThreadB tries to do unwinding as well.
* ThreadB, inside fdtrack's unwinding tries to grab the same mutex that
ThreadA is holding.
* Mutex contention is reported using bionic_systrace, therefore
bionic_trace_begin() is called again on ThreadB.
* ThreadB tries to grab g_lock in bionin_systrace.cpp, but that's
already held by ThreadB itself, earlier on the stack. Therefore
ThreadB is stuck.
I managed to reproduce the above scenario by manually pausing ThreadA
inside unwinding with a debugger and letting ThreadB hitting
bionic_trace_begin() for the first time.
We could avoid using g_lock while calling open() (either by releasing
g_lock and reacquiring it later, or by using atomics), but
bionic_trace_begin() would try to call open() again. In my tests, open()
does not call bionic_trace_begin() a third time, because fdtrack has
reentrancy protection, but there might be another code path inside open
that calls bionic_trace_begin again (it could be racy or only happen in
certain configurations).
This commit fixes the problem by implementing reentrancy protection in
bionic_systrace.
Sample callstack from ThreadA deadlocked before the fix:
```
* frame #0: 0x0000007436db077c libc.so`syscall at syscall.S:41
frame #1: 0x0000007436db0ba0 libc.so`bionic_trace_begin(char const*) [inlined] __futex(ftx=0x000000743737a548, op=<unavailable>, value=2, timeout=0x0000000000000000, bitset=-1) at bionic_futex.h:45:16
frame #2: 0x0000007436db0b8c libc.so`bionic_trace_begin(char const*) [inlined] __futex_wait_ex(ftx=0x000000743737a548, value=2) at bionic_futex.h:66:10
frame #3: 0x0000007436db0b78 libc.so`bionic_trace_begin(char const*) [inlined] Lock::lock(this=0x000000743737a548) at bionic_lock.h:67:7
frame #4: 0x0000007436db0b74 libc.so`bionic_trace_begin(char const*) [inlined] should_trace() at bionic_systrace.cpp:38:10
frame #5: 0x0000007436db0b74 libc.so`bionic_trace_begin(message="Contending for pthread mutex") at bionic_systrace.cpp:59:8
frame #6: 0x0000007436e193e4 libc.so`NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*) [inlined] NonPI::NormalMutexLock(mutex=0x0000007296cae9f0, shared=0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:592:17
frame #7: 0x0000007436e193c8 libc.so`NonPI::MutexLockWithTimeout(mutex=0x0000007296cae9f0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:719:16
frame #8: 0x0000007436e1912c libc.so`::pthread_mutex_lock(mutex_interface=<unavailable>) at pthread_mutex.cpp:839:12 [artificial]
frame #9: 0x00000071a4e5b290 libfdtrack.so`std::__1::mutex::lock() [inlined] std::__1::__libcpp_mutex_lock(__m=<unavailable>) at __threading_support:256:10
frame #10: 0x00000071a4e5b28c libfdtrack.so`std::__1::mutex::lock(this=<unavailable>) at mutex.cpp:31:14
frame #11: 0x00000071a4e32634 libfdtrack.so`unwindstack::Elf::Step(unsigned long, unwindstack::Regs*, unwindstack::Memory*, bool*, bool*) [inlined] std::__1::lock_guard<std::__1::mutex>::lock_guard(__m=0x0000007296cae9f0) at __mutex_base:104:27
frame #12: 0x00000071a4e32618 libfdtrack.so`unwindstack::Elf::Step(this=0x0000007296cae9c0, rel_pc=66116, regs=0x0000007266ca0470, process_memory=0x0000007246caa130, finished=0x0000007ff910efb4, is_signal_frame=0x0000007ff910efb0) at Elf.cpp:206:31
frame #13: 0x00000071a4e2b3b0 libfdtrack.so`unwindstack::LocalUnwinder::Unwind(this=0x00000071a4ea1528, frame_info=<unavailable>, max_frames=34) at LocalUnwinder.cpp:102:22
frame #14: 0x00000071a4e2a3ec libfdtrack.so`fd_hook(event=<unavailable>) at fdtrack.cpp:119:18
frame #15: 0x0000007436dbf684 libc.so`::__open_2(pathname=<unavailable>, flags=<unavailable>) at open.cpp:72:10
frame #16: 0x0000007436db0a04 libc.so`bionic_trace_begin(char const*) [inlined] open(pathname=<unavailable>, flags=524289) at fcntl.h:63:12
frame #17: 0x0000007436db09f0 libc.so`bionic_trace_begin(char const*) [inlined] get_trace_marker_fd() at bionic_systrace.cpp:49:25
frame #18: 0x0000007436db09c0 libc.so`bionic_trace_begin(message="pthread_create") at bionic_systrace.cpp:63:25
```
Bug: 213642769
Change-Id: I10d331859045cb4a8609b007f5c6cf2577ff44df
Unfortunately we have discovered that some applications in the wild
are using PAC instructions incorrectly. To keep those applications
working on PAC enabled devices, disable PAC in application processes
for now.
Bug: 212660282
Change-Id: I3030c47be9d02a27505bd4775c1982a20755758c
When we added the fast path for the common case of ASCII, we forgot to
remove the now-dead code that handled the 1-byte case later in these
functions. This was obvious from the code coverage data.
Note that the 16-bit variants are unaffected because they're implemented
as calls to the 32-bit variants with extra range checks/surrogate
handling surrounding the call.
Test: treehugger
Change-Id: Ibd40f823519acb9aae8037bdeb3f9c5e36b9d9a6
We could remove this line, but it seems reasonable to leave it in for
clarification/safety, especially if it's moved after the common success
case?
Test: treehugger
Change-Id: I5f7e0da8397f80018e6d55321b26371790087f5c
This came up with POSIX recently. Doesn't seem like it matters since
everyone's had this wrong for 40 years, but "meh" --- it's a trivial
fix, and it's strictly correct even if nobody needs this, so let's just
do it...
(Geoff Clare pointed out that my app compat concern "what if someone's
relying on this bug to pass flags to the shell?" isn't relevant because
while you can indeed do that, you then can't pass a command!)
Bug: https://austingroupbugs.net/view.php?id=1440
Test: treehugger
Change-Id: I64f6440da55e2dc29d0136ee62007197d2f00d46
This saves a couple of syscalls in the common case, and also lets static
binaries run in a chroot without /dev/null as long as
stdin/stdout/stderr are actually connected to something (which the
toybox maintainer tried to do).
Test: manual with strace
Change-Id: Ic9a28896a07304a3bd428acfd9ddca9d22015f6e
They're in glibc, though not in musl.
Also add basic doc comments to the whole of <sys/uio.h>.
Bug: http://b/203002492
Test: treehugger
Change-Id: Ic607f7f349e5b7c9bf66c25b7bd68f827da530d6
In the following scenario:
* Heapprofd wants to profile a process.
* The process receives the heapprofd signal, so it sets up the ephemeral
hooks.
* The process does not perform any allocation, so the proper heapprofd
hook is never installed.
* Heapprofd terminates.
* Now heapprofd wants to start a new profiling session.
* The process receives the heapprofd signal (again).
In the signal handler, no action is needed at this point. The ephemeral
hooks are already setup, so, at the next malloc, the proper heapprofd
hooks will be installed.
Before this commit, the code logged an error message, but still worked
correctly.
This commit basically just skips the error_log below.
Example of the error message that is now suppressed:
```
process: heapprofd: failed to transition kInitialState ->
kInstallingEphemeralHook. current state (possible race): 2
```
Tested by:
* Running a process that calls malloc on input from stdin.
* (Optional, tested both cases) Enable GWP-Asan by calling
`android_mallopt(M_INITIALIZE_GWP_ASAN, ...`. The call will return
success.
* Attaching heapprofd:
```
external/perfetto/tools/heap_profile -i 1 -p `adb shell pidof <...>`
```
* Detaching heapprofd (CTRL-C). The trace will be empty.
* (If not enabled before) Enabling GWP-Asan. The call will fail (because
GWP-Asan detects heapprofd hooks).
* Reattaching heapprofd.
* Triggering some malloc()s in the process. The error log from above
will not appear in `adb logcat`.
* Detaching heapprofd (CTRL-C). The trace will NOT be empty.
Bug: 192258849
Change-Id: I01699b10ecd19e52e1e77f83fcca955ebd885942
Strictly this still isn't quite the same, because they won't actually be
profiled, but at least they won't *crash* now if they're sent a
profiling signal.
Bug: http://b/201497662
Test: treehugger
Change-Id: I0728492eed77584cd850d28897056996387e6671
When calling write on an FD for trace_marker, it is expected that the
pointer passed will be paged into memory. If this isn't the case, the
kernel will ignore the string passed and instead write "<faulted>" to
the ring buffer.
For end events, we were passing a constant string which resides in
the rodata section of the ELF file. If this section is paged out, we
end up not closing atrace stacks correctly leading to very broken traces.
For even more context, see the associated bug.
Fix this issue by reading the constant string to the stack first
which should mean the string is always paged in.
Bug: 197620214
Change-Id: I6a444ac6fe83a6a9fb696c5621e392eca7e9437a
When calling android_mallopt using M_INITIALIZE_GWP_ASAN, nothing
was being returned. Fix this, add a test, and also refactor the
code a bit so dynamic and static share the same code.
Test: Unit tests pass in dynamic and static versions.
Test: Passed using both jemalloc and scudo.
Change-Id: Ibe54b6ccabdbd44d2378892e793df393978bc02b
musl libc doesn't provide fts, but elfutils and libabigail need it.
Export bionic's fts as a staic library that can be linked into elfutils
and libabigail when compiling against musl.
fts uses recallocarray, which musl doesn't provide, so also include
recallocarray.c in libfts.a.
Requires minor tweaks to fts.c and a wrapper around fts.h to make them
compatible with musl, primarily by providing local definitions of macros
provided in bionic's sys/cdefs.h.
Bug: 190084016
Test: m libfts
Change-Id: Ifac9a59e7504c0c1f5f8a3a5bd3c19a13980b83c
fts.c is from openbsd and has compatibility macros to make it compile
as part of bionic. Move it into libc_openbsd_ndk where it will
get the workarounds from -include openbsd-compat.h instead.
Test: m libc
Change-Id: I213d423af8f010e39460b611e902acbf3561ae7a
If the DispatchReset fails, the subsequent iteration has the wrong
idea of what the "original" table is, and if a subsequent DispatchReset
succeeds it unhooks them.
Repro in https://r.android.com/1767868.
Bug: 193012939
Bug: 189776979
Change-Id: I30445c053fcb785669f75d9c83056926d850edce
The posix spec says strerror_r returns a positive error number, not
-1 and set errno.
Test: bionic-unit-tests-static
Change-Id: I6a12d50d046f9caac299bf3bff63e6c9496c1b6f
Revert submission 1403568-sysprop_trace
Reason for revert: makes property get/set non-reentrant
Reverted Changes:
I6f85f3f52:Add systrace tag for system property
Id2b93acb2:Adding system property tracing
Id78992d23:Add systrace tag for system property
I1ba9fc7bd:Add systrace tag for system property
Bug: 193050299
Test: build and boot a device
Change-Id: Ic7a83fb01a39113d408ed0c95d27f694d5a2649c
Merged-In: Ic7a83fb01a39113d408ed0c95d27f694d5a2649c
(cherry picked from commit 61a5a8380d)
This reverts commit 1e1c7845aa.
Reason for revert: makes property get/set non-reentrant
Bug: 193050299
Test: build and boot a device
Change-Id: If59e3dc25684a3c2b1d3ff74f995311afe6c6e89
Merged-In: If59e3dc25684a3c2b1d3ff74f995311afe6c6e89
(cherry picked from commit 3ec21f527a)
On devices where the performance of ASYNC mode is similar to SYNC
mode on certain CPUs, OEMs may choose to configure the kernel to
prefer SYNC mode on those CPUs by writing the value "sync" to the
sysfs node: /sys/devices/system/cpu/cpu<N>/mte_tcf_preferred
The kernel will only respect the per-CPU preference if the user program
allows this by specifying the preferred mode as a member of a set of
allowed modes. Since only kernels with r.android.com/1754670 support
specifying multiple modes, fall back to trying to specify a single
mode if that doesn't work.
Bug: 189966263
Change-Id: Ie7ada3b073178b7967f0819cbdadc2d8e3a2c648
This function doesn't return, but it does appear in stack traces. Avoid
using return PAC in this function because we may end up resetting IA,
which may confuse unwinders due to mismatching keys.
Bug: 189808795
Change-Id: I953da9078acd1d43eb7a47fb11f75caa0099fa12
Extend existing restrictions targeting only apps with API level >= 30 to
all apps.
Actual enforcement happens in SELinux. This change just prevents
logspam.
To be merged when automerge to sc-dev ends.
Bug: 170188668
Test: atest bionic-unit-tests-static
Test: atest NetworkInterfaceTest
Test: Connect to Wi-Fi network
Test: atest CtsSelinuxTargetSdk27TestCases
Test: atest CtsSelinuxTargetSdk28TestCasesTest: atest
CtsSelinuxTargetSdk29TestCases
Test: atest CtsSelinuxTargetSdkCurrentTestCases
Change-Id: If1761354216b23a1e55e6b9606de452899afff0c
Processes loaded from vendor partitions may have their own sandboxes
that would reject the prctl. Because no devices launched with PAC
enabled before S, we can avoid issues on upgrading devices by checking
for PAC support before issuing the prctl.
Bug: 186117046
Change-Id: I9905b963df01c9007d9fb4527273062ea87a5075
Revert "Updates CTS tests for MAC address restrictions."
Revert submission 1528409-mac-softrestrict
Reason for revert: App compatibility
Reverted Changes:
I74a50b990:Return anonymized MAC for apps targeting SDK < 30
I8738f7912:Reland: Soft-enable MAC address restrictions with ...
Id13670747:Updates CTS tests for MAC address restrictions.
Change-Id: I64e17cb04acf2862bc657e60694067a456b4f936
Also delete some fdsan code that attempts to check for the post-fork
state, but never will, because we update the cached pid upon fork.
Bug: http://b/174542867
Test: /data/nativetest64/bionic-unit-tests/bionic-unit-tests
Test: treehugger
Change-Id: I9b748dac9de9b4c741897d93e64d31737e52bf8e
Resetting PAC keys on fork appears to lead to a number of problems. One
problem is that we are constrained in where we can run C++ code after
forking, and with ART those places are implementation-defined. For
example, in app zygotes, ART turns out to insert "interpreter frames"
in the stack trace. Returning into these interpreter frames may lead
to crashes due to failing the ROP protection check on return.
It seems better to reset keys on thread creation instead. We only need
to reset IA because only this key needs to be reset for reverse-edge
PAC, and resetting the other keys may be incompatible with future ABIs.
Chrome (and potentially other applications) has a sandbox that prevents
the use of the prctl, so we restrict its use to applications targeting
S and above.
Bug: 183024045
Change-Id: I1e6502a7d7df319d424e2b0f653aad9a343ae71b
This is the second or third time I've scratched my head wondering why
this destructor has no coverage. I was tempted to leave it in with a
comment saying it should never be called, but that seemed sillier than
just replacing it with an assertion.
Test: treehugger
Change-Id: I3442d9f8a391fae668e77c6888a4457ededee494
This works around buggy applications that read a few bytes past the
end of their allocation, which would otherwise cause a segfault with
the concurrent Scudo change that aligns large allocations to the right.
Because the implementation of
android_set_application_target_sdk_version() lives in the linker,
we need to introduce a hook so that libc is notified when the target
SDK version changes.
Bug: 181344545
Change-Id: Id4be6645b94fad3f64ae48afd16c0154f1de448f
Spotted while looking at our shiny new coverage numbers. Though how the
change that removed the code from this file without removing the file
made it through code review... Clearly I wasn't paying attention that
day!
Test: treehugger
Change-Id: Id61bb48bae60660d2e5ba9b26f00a68e51157c6d
__libc_init_scudo() calls directly into the allocator, bypassing the
normal guest to host transition in the native bridge. Therefore we
need to let the native bridge override it with a no-op.
Bug: 159352723
Change-Id: I642c7a058e483cc09335290f66b9c053150fca06
This is undefined behavior, but glibc and macOS are both lenient, and
someone hit this in the wild, so we may as well be lenient too. (The
only cost is that it's now slightly easier to write code that works on
everything except old versions of Android.)
Bug: https://issuetracker.google.com/180598400
Test: treehugger
Change-Id: Ia217169ea6283cc53f4fbf71e5abfa08356c2049
With this change we can report memory errors involving secondary
allocations. Update the existing crasher tests to also test
UAF/overflow/underflow on allocations with sizes sufficient to trigger
the secondary allocator.
Bug: 135772972
Change-Id: Ic8925c1f18621a8f272e26d5630e5d11d6d34d38
Introduces new heap-zero-init API. We've realised that it's better to be
able to individually control MTE and heap zero-init. Having
heap-zero-init not be controllable without affecting MTE affects our
ability to turn off heap-zero-init in zygote-forked applications.
Bug: 135772972
Test: On FVP: atest -s localhost:5555 malloc#zero_init \
Test: malloc#disable_mte heap_tagging_level
Change-Id: I8c6722502733259934c699f4f1269eaf1641a09f
scudo_malloc_* for fill contents in __libc_init_scudo calls scudo's
initializers. We haven't told Scudo whether we want MTE-capable (i.e.
mapped with PROT_MTE) size class regions yet, which happens in
SetDefaultHeapTaggingLevel. This can lead to inconsistent mappings,
where processes without ELF notes get the base region with PROT_MTE
(which is undesirable because the performance implications are not
known).
Make sure that scudo is informed of whether regions need to be mapped
PROT_MTE or not by hoising the tagging level up.
Bug: 135772972
Bug: 172365548
Test: On FVP - 'adb shell MEMTAG_OPTIONS=off sanitizer-status' should
have no PROT_MTE mappings (validation by looking for no 'mt' under
'VmFlags:' in /proc/smaps').
Change-Id: Idad64479c4a9459cb40dd211fe942437f8ca16fd
These are available from mallopt() now, and all callers have been
switched over.
Bug: http://b/135772972
Test: treehugger
Change-Id: I90c7a7573b261c27001a2dfd4589b23861ad613b
These were only available internally via android_mallopt(), but they're
likely to be needed by more code in future, so move them into mallopt().
This change leaves the android_mallopt() options for now, but I plan on
coming back to remove them after I've switched the handful of callers
over to mallopt() instead.
Bug: http://b/135772972
Test: treehugger
Change-Id: Ia154614069a7623c6aca85975a91e6a156f04759
These two options allow for ARM MTE to be enabled dynamically (instead
of at compile time via the ELF note). They are settable from a non-root
shell to allow device owners to test system binaries with MTE.
The following values may be set:
1. 'off' -> No MTE, uses TBI on compatible devices.
2. 'sync' -> SYNC MTE.
3. 'async' -> ASYNC MTE.
The following methods can be used to launch a process (sanitizer-status)
with configurable values:
1. adb shell MEMTAG_OPTIONS=async sanitizer-status
2. adb shell setprop arm64.memtag.process.sanitizer-status async && \
adb shell sanitizer-status
Note: The system server will require some special handing in the zygote
pre-fork to check the sysprops. The zygote should always have the ELF
note. TODO in a subsequent patch.
Bug: 135772972
Bug: 172365548
Test: Launching sanitizer-status above using both the settings.
Change-Id: Ic1dbf3985a3f23521ec86725ec482c8f6739c182
Now that the feature guarded by this flag has landed in Linux 5.10
we no longer need the flag, so we can remove it.
Bug: 135772972
Change-Id: I02fa50848cbd0486c23c8a229bb8f1ab5dd5a56f
I realize that we can probably clean up more of our half-forked code by
reusing the same *-compat.h headers we use for the clean upstream code,
but I'll come back and do that later.
Bug: http://b/177003648
Test: treehugger
Change-Id: I081255aaafd62718b85956c5502911a1cc80225d
Technically, std::atomic does not have an operator(). Previously, this
code was relying on an implicit behavior of our C++ standard library in
order to compile. When compiling this code against a different C++
standard library, I encountered a compiler error on these lines.
This CL makes the std::atomic load() operation explicit, makes it
clearer what this code is actually doing and makes it conform better to
the C++ standard library spec rather than a particular implmentation.
Change-Id: I7f255dffc0a3d8e07c973c18e9ba4098c4b5843e
Technically, C requires that all source files end with a newline. In
practice, most compilers will accept source files without a newline, but
it does trigger the -Wnewline-eof warning.
Change-Id: I64a92b82f4d5724cd8b45821cfd59eb3de39514b
Use a note in executables to specify
(none|sync|async) heap tagging level. To be extended with (heap x stack x
globals) in the future. A missing note disables all tagging.
Bug: b/135772972
Test: bionic-unit-tests (in a future change)
Change-Id: Iab145a922c7abe24cdce17323f9e0c1063cc1321
Soft-limits apps from calling bind() on NETLINK_ROUTE sockets, and
getting link info through getifaddrs(), while still allowing apps on the
allowlist to temporarily perform these actions.
This is different from existing behavior, where apps targeting an API
level < 30 were exempted from this restriction.
Actual enforcement will happen through SELinux (as is currently the
case for apps targeting API >= 30). This temporary change will then be
reverted.
If you arrived at this change due to an app showing unexpected behavior,
please file a bug at go/netlink-bug.
Bug: 170188668
Bug: 170214442
Test: Call bind() on NETLINK_ROUTE for an app on the allowlist.
Test: Call bind() on NETLINK_ROUTE for an app not on the allowlist.
Test: Call getifaddrs() for an app on the allowlist.
Test: Call getifaddrs() for an app not on the allowlist.
Test: Call bind() on a AF_UNIX socket with its protocol set to
NETLINK_ROUTE, confirm it can succeed.
Test: Verify that previously broken apps are no longer broken.
Change-Id: I8738f7912fdc816e0d30205557728ff9e84bf7e6
Revert "Updates CTS tests for MAC address restrictions."
Revert submission 1518603-soft-restrict-mac
Reason for revert: Missing type check
Reverted Changes:
I0488932de:Soft-enable MAC address restrictions with allowlis...
Idb9d940e4:Updates CTS tests for MAC address restrictions.
I9461f287e:Return anonymized MAC for apps targeting SDK < 30
Change-Id: I7e8e593518088ff5c8f6083b34e6966852475b9b
This was a little confusing because a quick glance suggested that
'err' was getting the value of getsockopt(), when actually it was
getting the result of the '<' operation. Since 'err' wasn't
being used, we clarify by just removing it altogether.
Test: TreeHugger
Change-Id: I1ff80812b460973e9d512a558623e0c44c2ecf09
Soft-limits apps from calling bind() on NETLINK_ROUTE sockets, and
getting link info through getifaddrs(), while still allowing apps on the
allowlist to temporarily perform these actions.
This is different from existing behavior, where apps targeting an API
level < 30 were exempted from this restriction.
Actual enforcement will happen through SELinux (as is currently the
case for apps targeting API >= 30). This temporary change will then be
reverted.
If you arrived at this change due to an app showing unexpected behavior,
please file a bug at go/netlink-bug.
Bug: 170188668
Bug: 170214442
Test: Call bind() on NETLINK_ROUTE for an app on the allowlist.
Test: Call bind() on NETLINK_ROUTE for an app not on the allowlist.
Test: Call getifaddrs() for an app on the allowlist.
Test: Call getifaddrs() for an app not on the allowlist.
Change-Id: I0488932deea2a7211e55a24bc33bfa3cfb16fba2
They're both obsolescent in POSIX.1-2008, and you really shouldn't be
using them, but since we can't actually delete them...
This change makes them both obey $TMPDIR if set, and fall back to
/data/local/tmp otherwise. That's as good as we've managed for anything
else such as tmpfile(3).
Also add some tests.
Bug: http://b/174682340
Test: treehugger
Change-Id: Ieef99dcc2062f84b2b7cbae046787fdfe975e772
We can sometimes fail to link a static executable because of
duplicate definitions of std::nothrow in bionic/libc/bionic/new.cpp
and external/libcxx/src/new.cpp. Fix it by making our definition
weak since it doesn't matter which one ends up being chosen.
Change-Id: Iec02ae89f4a3d2ffe298817240f404e54b109a52
aosp/1484976 introduced a breaking change where
DisableMemoryMitigations() now indiscriminately turns tagged pointers
off. When android_mallopt(M_DISABLE_MEMORY_MITIGATIONS) is called, the
correct behaviour is:
- In SYNC/ASYNC MTE mode -> disable all tagged pointers.
- If all tagged pointers are already disabled -> nop.
- If we're in TBI mode -> nop (keep the TBI mode as-is).
In order to do that we have to allow probing of the current heap tagging
mode. In order to prevent TOCTOU between GetHeapTaggingLevel() and
SetHeapTaggingLevel(), we expose a global mutex that should be held when
calling these functions.
Bug: 174263432
Test: atest CtsTaggingHostTestCases on Flame
Change-Id: Ia96f7269d542c9041270458806aee36766d2fbbb
Unnecessary include, and the file was deleted with upstream changes.
Bug: N/A
Test: cd external/gwp_asan && atest
Change-Id: Id8facff0c5e382aa639ce158b7b5862ce157aa25
- Make it apply to every thread, and thus remove the restriction
that it must be called while the program is single threaded.
- Make it change TCF0 itself (on all threads), instead of requiring
callers to do it themselves, which can be error prone.
And update all of the call sites.
Change the implementation of
android_mallopt(M_DISABLE_MEMORY_MITIGATIONS) to call
android_mallopt(M_SET_HEAP_TAGGING_LEVEL) internally. This avoids
crashes during startup that were observed when the two mallopts
updated TCF0 unaware of each other.
I wouldn't expect there to be any out-of-tree callers at this point,
but it's worth noting that the new interface is backwards compatible
with the old one because it strictly expands the set of situations in
which the API can be used (i.e. situations where there are multiple
threads running or where TCF0 hadn't been updated beforehand).
Bug: 135772972
Change-Id: I7746707898ff31ef2e0af01c4f55ba90b72bef51
259776d8ff
The original change was reverted due to InterfaceParamsTest failing.
This test has now been fixed in r.android.com/1498525.
The original change message is below.
Updates getifaddrs() to behave as if RTM_GETLINK requests are not
allowed for non-system apps. This is different from previous behavior,
where apps targeting an API level < 30 were exempted from this
restriction.
Actual enforcement happens in SELinux. This change:
- Soft-enables the behavior until SELinux changes are in place
- Prevents logspam from SELinux denials after they are in place
Bug: 170188668
Test: atest bionic-unit-tests-static
Test: atest NetworkInterfaceTest
Test: Connect to Wi-Fi network
Test: Call getifaddrs() directly from within an app.
Test: Call NetworkInterface#getNetworkInterfaces() from within an app.
Change-Id: Ia9f61819f8fdf878c0e67e57de7e893fb3b1c233
Revert "Enforce RTM_GETLINK restrictions on all 3p apps"
Revert "Updates tests for untrusted app MAC address restrictions"
Revert submission 1450615-mac-address-restrictions
Reason for revert: DroidMonitor: Potential culprit for Bug 173243616 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted
Reverted Changes:
I08c709b2b:Enforce RTM_GETLINK restrictions on all 3p apps
I95d124ae8:Soft-enables new MAC address restrictions.
I5392f8339:Updates tests for untrusted app MAC address restri...
I9d214c5d0:Return anonymized MAC for apps targeting SDK < 30
Change-Id: If09920b24370077d647d60cfda7fc0a110b77851
A constructor or destructor function with an integral priority is
placed in an .init_array or .fini_array section with the priority
suffixed to the section name:
- __attribute__((constructor)) ==> .init_array
- __attribute__((constructor(42))) ==> .init_array.42
The suffixed init/fini sections appear before the unsuffixed sections,
so the prioritized functions appeared before the __{INIT,FINI}_ARRAY__
symbols and were dropped when the symbols were used.
The (static) linker doesn't recognize priority suffixes on
.preinit_array.
This bug affected .init_array and .fini_array for static executables.
For dynamic executables, only .fini_array was affected, because
.init_array is handled by the dynamic loader instead, which uses
DT_INIT_ARRAY[SZ]. For DSOs, neither is affected, because the two
sections are only handled by the dynamic loader.
This patch also fixes a minor inconsistency where dynamic init/preinit
were passed argc/argv/envp, but static were not.
Bug: http://b/170983066
Test: bionic-unit-tests
Change-Id: I0fffa776e5d9bdb6f8af06b4c1af148236742fef
The functions now read /etc/group and /etc/passwd on host machines.
Android-specific IDs are not recognized in the host.
getpwent and getgrent are still not working though. They require a
bigger refactoring to sequentially advance in the database files.
Bug: 171718702
Test: run assemble_cvd in aosp_cf_arm64_phone
Change-Id: Ie8da382a467bbd0bffac7b4b8592cd871db80181
/system/bin/sh exists only on Android. When Bionic is built for the
host, use the standard /bin/sh.
Bug: 159685774
Test: run aosp_cf_arm64_phone on rockpi4
Change-Id: Idf4028c134abc128f203fc4d3be591f06b8fe8ff
When an array element is added or removed, make only the relevant page
writable, rather than the entire array. The entire array is still made
writable during recompaction and expansion.
This change fixes most of a large regression in __cxa_atexit runtime
(blueline, taskset 10, performance governor, 100000 registrations,
times are in seconds)
- Q: _Exit=0.292380, exit=0.626801
- R: _Exit=28.435082, exit=95.785110
- new: _Exit=0.352285, exit=0.713893
Test: bionic unit tests
Test: adb shell taskset 10 \
/data/benchmarktest64/bionic-spawn-benchmarks/bionic-spawn-benchmarks \
--benchmark_filter='atexit' \
--benchmark_display_aggregates_only=true \
--benchmark_repetitions=10
Bug: http://b/168043760
Change-Id: I88cc15c29c9890b422b7f621f29f98a03ca1f886
pthread_cond_pulse would unconditionally call futex, which meant that
a number of processes were spending a significant amount of time in
pthread_cond_broadcast and pthread_cond_signal when there were no
threads waiting on that pthread_cond_t.
This change adds a counter to the 64-bit pthread_cond_t struct and
only calls futex() in cases where there is a nonzero waiter count. The
32-bit pthread_cond_t is unchanged due to compatibility reasons.
Test: no pthread_cond_broadcast/signal stacks without try_to_wake_up
in SurfaceFlinger
bug: 168831708
Change-Id: I105e1345cd2a3a75f98cd0acf316e790ba1716f0
Introduce an android_mallopt(M_DISABLE_MEMORY_MITIGATIONS) API call
that may be used to disable zero- or pattern-init on non-MTE hardware,
or memory tagging on MTE hardware. The intent is that this function
may be called at any time, including when there are multiple threads
running.
Disabling zero- or pattern-init is quite trivial, we just need to set
a global variable to 0 via a Scudo API call (although there will be
some separate work required on the Scudo side to make this operation
thread-safe).
It is a bit more tricky to disable MTE across a process, because
the kernel does not provide an API for disabling tag checking in all
threads in a process, only per-thread. We need to send a signal to each
of the process's threads with a handler that issues the required prctl
call, and lock thread creation for the duration of the API call to
avoid races between thread enumeration and calls to pthread_create().
Bug: 135772972
Change-Id: I81ece86ace916eb6b435ab516cd431ec4b48a3bf
Updates getifaddrs() to behave as if RTM_GETLINK requests are not
allowed for non-system apps. This is different from previous behavior,
where apps targeting an API level < 30 were exempted from this
restriction.
Actual enforcement happens in SELinux. This change:
- Soft-enables the behavior until SELinux changes are in place
- Prevents logspam from SELinux denials after they are in place
Bug: 170188668
Test: atest bionic-unit-tests-static
Test: atest NetworkInterfaceTest
Test: Connect to Wi-Fi network
Test: Call getifaddrs() directly from within an app.
Test: Call NetworkInterface#getNetworkInterfaces() from within an app.
Change-Id: I95d124ae81bcb26583db5ad01d95d441d52f973c
