API level 19 is no longer supported by the NDK.
While I'm here, let's remove the duplicated structure defintion (as
we've already done for `struct stat`).
Test: treehugger
Change-Id: I9d8286f9e7ba803f3131b6dcb0486ff1b0f9d5d1
This mode allows an android_mallopt(M_INITIALIZE_GWP_ASAN, ...) to turn
on the recoverable, sampled mode. This is the intended mode for
non-system apps that don't specify the gwpAsanMode in Android U.
Bug: 247012630
Test: Patch the zygote to use this option, launch an app with
gwpAsanMode unspecified, trigger a use-after-free, assert the app uses
the recoverable mode.
Change-Id: I701e10f44b2e2694789cc5ec6f0af4bc0c55b9e4
GWP-ASan's recoverable mode was landed upstream in
https://reviews.llvm.org/D140173.
This mode allows for a use-after-free or a buffer-overflow bug to be
detected by GWP-ASan, a crash report dumped, but then GWP-ASan (through
the preCrashReport() and postCrashReportRecoverableOnly() hooks) will
patch up the memory so that the process can continue, in spite of the
memory safety bug.
This is desirable, as it allows us to consider migrating non-system apps
from opt-in GWP-ASan to opt-out GWP-ASan. The major concern was "if we
make it opt-out, then bad apps will start crashing". If we don't crash,
problem solved :). Obviously, we'll need to do this with an amount of
process sampling to mitigate against the 70KiB memory overhead.
The biggest problem is that the debuggerd signal handler isn't the first
signal handler for apps, it's the sigchain handler inside of libart.
Clearly, the sigchain handler needs to ask us whether the crash is
GWP-ASan's fault, and if so, please patch up the allocator. Because of
linker namespace restrictions, libart can't directly ask the linker
(which is where debuggerd lies), so we provide a proxy function in libc.
Test: Build the platform, run sanitizer-status and various test apps
with recoverable gwp-asan. Assert that it doesn't crash, and we get a
debuggerd report.
Bug: 247012630
Change-Id: I86d5e27a9ca5531c8942e62647fd377c3cd36dfd
It makes sense that callers to getauxval() should have to pay for a
search --- that's exactly what they're asking for. But it seems silly
and unfair for the same to be true of sysconf() --- that's just an
implementation detail. Call getpagesize() directly instead.
Test: treehugger
Change-Id: I327adc55ace73bc6da68c4b34bf829d377bcbd1a
This is a no-op but will be used in upcoming scudo changes that allow to
change the buffer size at process startup time, and as such we will no
longer be able to call __scudo_get_ring_buffer_size in debuggerd.
Bug: 263287052
Change-Id: I18f166fc136ac8314d748eb80a806defcc25c9fd
We still have local differences, but this minimizes (and documents) them.
Bug: http://b/167569813
Test: treehugger
Change-Id: Ib90e6ccc5ec1224e7ee89224a51b87fc48c9931f
Treehugger didn't test 32-bit (and neither, of course, had I), so we
didn't notice until the next day that I'd only added the new check to
the 64-bit codepath. Let's just unify the two, since there's only one
line of meaningful difference.
Bug: http://b/261092827
Test: treehugger
Change-Id: I5178257a76fe24a340b3659c85ad29ed0a7b8b50
These two will stay behind when we move memcpy()/memmove()/memset() over
to arm-optimized-routines (which leaves fortify to us).
Test: treehugger
Change-Id: Ie683f71a5a141263ce3f4e8811df9eaf667584f4
I can't find this documented anywhere, other than people observing that
RISC-V appears to behave in this way. See the LLVM commit making a
similar change to similar code, for example: https://reviews.llvm.org/D87579.
Unsatisfying, but it works, and I suspect we're all too far down this
copy & paste hole to get back out now. See also psabi bug
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/18 for
more discussion.
Change-Id: I9e9d60bf859715895370861b2024deeb1d330577
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
These have been aliases for strtoll() and strtoull() since L, by
accident. We've never exposed them in the headers, and they're unused by
any apps. Let's fix the inconsistency between libc.so and its headers by
removing the aliases.
Bug: https://github.com/android/ndk/issues/1803
Test: treehugger
Change-Id: I87de7831c04b3e450a44e9f0386cacb73793e393
Actually, we don't want to reuse the kernel struct ucontext because its
uc_mcontext has the wrong type, which means the fields within that end
up with the wrong names. Add the call site that made that evident, and
update <sys/ucontext.h> appropriately.
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: treehugger
Change-Id: If1d079afef0d5953aa22d9b0e049cfb0119c7718
risc-v doesn't have renameat(2), only renameat2(2). Similar to other
architectures, let's make sure everyone's on the same code path by
having all implementations of renameat() go via renameat2().
I've also moved the existing rename()-in-terms-of-renameat() to be in
terms of renameat2() to cut out the middleman!
Test: treehugger
Change-Id: Ibe5e69aca5b39ea014001540bcd4fd3003e665cb
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
