Since Treble, /vendor components has been using /vendor/bin/sh. But this
gets complicated with APEXes, /odm, apps, etc. We now switch back to
/system/bin/sh for all domains. In practice, this should be okay because
/system/bin/sh is almost stable.
Bug: 324142245
Test: system("readlink /proc/$$/exe") in vendor components
Change-Id: Id830aa8281e7cbda1f15474174c38d8e28dc358b
Also enable stack MTE if main binary links in a library that needs it.
Otherwise the following is possible:
1. a binary doesn't require stack MTE, but links in libraries that use
stg on the stack
2. that binary later dlopens a library that requires stack MTE, and our
logic in dlopen remaps the stacks with MTE
3. the libraries from step 1 now have tagged pointers with missing tags
in memory, so things go wrong
This reverts commit f53e91cc81.
Reason for revert: Fixed problem detected in b/324568991
Test: atest memtag_stack_dlopen_test with MTE enabled
Test: check crash is gone on fullmte build
Change-Id: I4a93f6814a19683c3ea5fe1e6d455df5459d31e1
For devices with ro.board.api_level >= 202404, use /system/bin/sh for
all domains include /vendor and other partitions.
Bug: 324142245
Test: system("readlink /proc/$$/exe") in vendor components
Change-Id: Ifa4f38e542377ce1482516fba4f0001c09c5a869
initgroups() is just a call to getgrouplist() followed by a call to
setgroups(). The tricky part is memory allocation. OpenBSD allocates an
NGROUPS_MAX-sized array of gid_t on the stack. FreeBSD allocates a
sysconf(_SC_NGROUPS_MAX)-sized array of gid_t on the heap. bionic had a
mix where it would try a 2-element stack array but fall back to a heap
allocation, which sounds reasonable if you want to avoid a 256KiB
(64Ki*4 bytes) allocation on either stack or heap. But that constant 2?
That's weird in two ways... It's really small (musl has an NGROUPS_MAX
of 32 unlike the Linux kernel's 64Ki, but 32 is still a lot larger than
2), but at the same time it's too big --- bionic's getgrouplist() always
returns a single element.
So although the FreeBSD "what the hell, let's just allocate 256KiB on
the heap" implementation would have been fine, there's really no point,
and anyone who's trying to understand initgroups() on Android really
needs to read getgroupslist() anyway, so let's just have the most
trivial implementation -- a single-element array -- and let's have it
right next to getgroupslist() in the same file as all the other <grp.h>
functions.
Also add a trivial smoke test. You mostly won't have permission to do
anything interesting with initgroups(), and it's basically unused save
for privilege dropping tcpdump and strace, but we may as well make an
effort. (I tested tcpdump before and after too.)
Test: treehugger
Change-Id: I67fe02e309ed1dbefc490c01733738363ca606be
The previous implementation wasn't wrong (it returned the "maximum
maximum"), but we can return the actual runtime value from the kernel.
Noticed while looking at initgroups().
Test: treehugger
Change-Id: I891fe4ff29bd82ee05d9e05ed8299d32c21abd7f
This is for advanced use-cases that have high performance demands and
know they will repeatedly re-use the crash_detail.
Bug: 155462331
Change-Id: Ib15dac70d1d598f78b74b539aeadf88b0ca32bc7
llvm-libc will reuse parts of the existing system headers for types that have
implications on the ABI.
Fixes:
error: external/llvm-libc/Android.bp:3:1: module "llvmlibc" variant
"android_recovery_riscv64_static": depends on //bionic/libc:libc_headers
which is not visible to this module You may need to add
"//external/llvm-libc" to its visibility
Test: TH
Bug: 321313756
Change-Id: I33b93d8e1617a480249641dc2cdf4bbee9f9e19d
These files were segregated because they were lacking a little cleanup.
Unfortunately that means this change has to do some of the cleanup, but
that's probably for the best.
Test: treehugger
Change-Id: I2dd33504787fc3313995de99e0745a0df22915b3
This reverts commit 79c9694c91.
Reason for revert: DroidMonitor: Potential culprit for Bug b/324348078 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I32f7bc824900e18a7d53b025ffe3aaef0ee71802
Factor out generic __get_elf_note() logic and rename __get_elf_note() to
__find_elf_note(). Expose __get_elf_note() in libc/private/bionic_note.h
This will be used in the subsequent patch to test the presence of
NT_ANDROID_TYPE_PAD_SEGMENT note when loading segments.
Test: atest -c linker-unit-tests [Later patch]
Test: m && launch_cvd
Bug: 316403210
Change-Id: Ia7cb2f40b10cfaef402182a675087c8422b37e4d
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
BYPASS_INCLUSIVE_LANGUAGE_REASON="man" refers to manual not person
Bug: 318749472
Test: atest pthread on MTE enabled device
Test: atest memtag_stack_dlopen_test on MTE enabled device
Test: manual with NDK r26b built app with fsanitize=memtag-stack
Change-Id: Iac191c31b87ccbdc6a52c63ddd22e7b440354202
This CL is created as a best effort to migrate test targets to the new Android ownership model.
It is based on historical data from repository history and insights from git blame.
Given the nature of this effort, there may be instances of incorrect attribution. If you find incorrect or unnecessary
attribution in this CL, please create a new CL to fix that.
For detailed guidelines and further information on the migration please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
Change-Id: Ie36b2a3245d9901323affcc5e51dafbb87af9248
The motivation for these is long gone, and now they only serve to
distract/duplicate.
Test: treehugger
Change-Id: I28f4ea6dd02fb564a15ab23b9f70d447ddf0c090
In particular: 32-bit x86 doesn't need sa_restorer either.
I still don't fully understand why arm32 and x86-64 do, so I've left the
comments in those .S files alone. I haven't (knowingly) tested
compiler-rt since we switched from libgcc (which is what the comments
refer to), but I have tested libunwindstack since we switched from
libunwind, and that does fail existing bionic tests for unwinds through
signal frames --- I just don't know why, or whether there's a better fix.
Anyway, local testing suggests that the 32-bit x86 code is vestigial, so
let's get rid of it.
Test: treehugger
Change-Id: I3e2616f736d27a8463814356e5adb52fd76a90cc
clang complains if you define a symbol and _then_ make it weak, rather
than the other way round:
/tmp/setjmp-c3c977.s:90:1: warning: sigsetjmp changed binding to STB_WEAK
.weak sigsetjmp;
^
Test: treehugger
Change-Id: Iee6b0ea456bb2e92aea810ce45f171caabaa89d2
I haven't seen this cause a problem in practice --- I noticed this while
looking at something else entirely.
Test: llvm-objdump
Change-Id: I56e38165f45554ede538a50439f8e8ffe72871c8
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.7
NOTE: The file bionic/libc/kernel/uapi/linux/usb/f_accessory.h was
deleted in the 6.7 kernel along with the functionality. However,
there is no current replacement. For now keep the file here, but at
some point when the new implementation is ready, this file will need to
be moved to the places that still need to be backwards compatible.
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: Ibf5684ed140616c02bb9464bbd6422a9281a29cf
crt_pad_segment provides a note of type NT_ANDROID_TYPE_PAD_SEGMENT.
It's intended when present is for the loader to pad segment gaps to
reduce kernel slab memory usage (due to additional vm_area_struct's
for gaps). crt_pad_segment.o retains control to the static linker so
that app developers can opt out (build with different flags) it there
are undesireable side effects.
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .strtab STRTAB 0000000000000000 0000f8 000066 00 0 0 1
[ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4
[ 3] .note.GNU-stack PROGBITS 0000000000000000 000040 000000 00 0 0 1
[ 4] .note.android.pad_segment NOTE 0000000000000000 000040 00001c 00 A 0 0 4
[ 5] .rela.note.android.pad_segment RELA 0000000000000000 0000e0 000018 18 I 7 4 8
[ 6] .debug_line PROGBITS 0000000000000000 00005c 000052 00 0 0 1
[ 7] .symtab SYMTAB 0000000000000000 0000b0 000030 18 1 1 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
Bug: 316403210
Test: m -j50 ndk
Test: find out/soong/ndk -name 'crt_pad_segment.o'
Test: readelf -SW crt_pag_segment.o
Change-Id: I94af5e85fd602e7ba5fd56788ae39277368229d8
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
std::atomic<T>'s default constructor is no longer trivial, because it
now does value-initialization. As a result, the class is no longer
trivial, so libc_globals is no longer trivial, so it is no longer POD.
(FWIW, the "POD" notion has been deprecated in favor of "trivial" and
"standard layout" concepts: POD == trivial + stdlayout.)
See https://cplusplus.github.io/LWG/issue2334 and wg21.link/p0883r2.
Mark __libc_globals as constinit, because that seems closer to
something we actually care about, AFAICT.
Bug: http://b/175635923
Test: m libc_malloc_debug
Change-Id: I338589bce03d06f20752bca342eeb86a42fc1ee7
builds
Use a soong config var to control if we should use a large sys prop node
size. Node in prop_area.cpp, the PA_SIZE is controlled by a macro flag.
This macro flag is passed in as a compiler flag which is then added when
the soong configure variable (large_system_property_node) is true.
The sooong configure variable is then backed by a build system flag
defined in build/release/build_flags.scl. The value of this flag is then
determined by different release configurations. Only internal build
release configuration would set this flag to true.
Bug: b/316932568
Change-Id: Ibe2ffda9155246f2217aaa0e7d589ed7effec311
The libraries are
- libdl_static
- liblinker_main
- liblinker_malloc
- libsystemproperties
The availability to runtime apex was done implicitly using a baseline map in
build/soong/apex/apex.go. Make this explicit in Android.bp
Bug: 281077552
Test: m nothing
Change-Id: I029ae204f6cfef8c301a20b7c4294636b60b38be
This reverts commit 46cce48995.
Reason for revert:
Will put a change behind flags to bump storage to 1Mb for internal build only. AOSP code does not need to be changed. The change will be only made to git_main.
Change-Id: If3484d0e56f4c3d8fc729f55744c2d8ebdd13b11
While aconfig flag storage is being migrated to its own dedicated
storage, we need to provide some relief to the current flag users which
are running into storage capacity limit of system property. Currently
system property by default allocates a file of 128Kb for each storage
node. Bump it to 256Kb for now.
Bug: b/316037066
Change-Id: I8b0b58733f362c3789ec92ae09ee589c7c1b72c6
The main change here is to remember that we arm64/x86-64 have flags, and
__builtin_<op>_overflow() lets us look at them. There's a clear saving
for arm64, and x86-64 is better too, though interestingly there the
unsigned case doesn't work out as well as the signed case because both
unsigned __builtin_mul_overflow and unsigned __builtin_add_overflow are
less efficient than the signed multiply and subtract on that
architecture, but the new code still beats the old code even so.
There's a very tiny microoptimization of the hex path that takes
advantage of the fact that conversion to lowercase is a single
instruction on all our architectures when we already know we're dealing
with a letter.
This also merges the signed and unsigned variants of the code. Not
entirely successfully, but the vast majority of the code benefits.
Before (arm64):
```
----------------------------------------------------------------
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_inttypes_strtoimax 44.6 ns 44.3 ns 15807654
BM_inttypes_strtoumax 43.1 ns 42.8 ns 16348848
BM_stdlib_strtol 44.6 ns 44.3 ns 15805384
BM_stdlib_strtol_hex 85.5 ns 85.0 ns 8235487
BM_stdlib_strtoll 44.5 ns 44.2 ns 15833137
BM_stdlib_strtoul 43.1 ns 42.8 ns 16353963
BM_stdlib_strtoul_hex 83.1 ns 82.6 ns 8477732
BM_stdlib_strtoull 43.1 ns 42.8 ns 16353015
```
After (arm64):
```
----------------------------------------------------------------
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_inttypes_strtoimax 37.9 ns 37.6 ns 17657577
BM_inttypes_strtoumax 35.9 ns 35.7 ns 19597727
BM_stdlib_strtol 36.9 ns 36.7 ns 19093037
BM_stdlib_strtol_hex 70.7 ns 70.3 ns 9961626
BM_stdlib_strtoll 36.9 ns 36.7 ns 19093032
BM_stdlib_strtoul 35.9 ns 35.7 ns 19617784
BM_stdlib_strtoul_hex 67.7 ns 67.3 ns 10113521
BM_stdlib_strtoull 35.9 ns 35.7 ns 19621828
```
Test: treehugger
Change-Id: Ibf53b29e34d63ac31520c6d27ef80ff281899d61
Actually reusing the hash table stuff from the linker would be a lot of
work (and the benefit unclear for so few symbols), but we can at least
break out of loops as soon as we have what we need.
Test: treehugger
Change-Id: I9cbe4636a3e3163bd302c3676eb674a4278dbf2e
Set PTHREAD_STACK_MIN will be set to:
- 16384 for 64-bit arch
- 8192 for 32-bit arch
Bug: 315174209
Test: Built and start the targets
- aosp_cf_arm64_phone_pgagnostic
- aosp_cf_x86_64_phone
Change-Id: I8bb20a3433e615f9f80a0d52051f2e1635d4301a
This reverts commit ef867550ac.
Reason for revert: a change to a python script run as a commit hook cannot cause a golang crash during builds.
Change-Id: Id63d4ea370e36f890a140b9e1bc69482e3610c42
This reverts commit adb8af2668.
Reason for revert: DroidMonitor: Potential culprit for Bug 315240955 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
BUG: 315240955
BUG: 315240463
Change-Id: I9f7297c6ca48728a91f7f4640ac19f901effb3cc
I don't think we need this, and we're not doing it for the equivalent
code in riscv64. So either we do need it, and this will help us find out
quicker and make the corresponding riscv64 change, or we don't need it,
and this is a free cleanup.
Test: treehugger
Change-Id: Ie97492ea8bb4d1bc69f926980d9d4db798884285
This way, callees don't need to worry about whether or not their
reference to __riscv_hwprobe() has been resolved before their ifunc
resolver is called.
This matches the current glibc proposal from rivos.
Test: treehugger
Change-Id: I0d5244aa837d0d1f0e6bd7d22091dfedb8a55bdb
There is no need to use PAGE_SIZE to define the value of
PTHREAD_STACK_MIN.
Bug: 312546062
Bug: 313941999
Test: source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic-trunk-userdebug
m
Change-Id: If3c3fe39f50592df58634d1c164e87dcd0aebad0
This works out a bit silly/ugly because the bits/ header file has the
wrong name, so I've also changed the map from kernel struct to boolean
to be a map from kernel struct to filename. That not only fixes this,
it's a bit more readable too. (Just yesterday, when I had no real reason
to change it, I was asking myself "why is this a boolean?"!)
Bug: http://b/236042740
Test: treehugger
Change-Id: I3eee25b493ea97d46cc5dc5fde07f7c5e77d2a46
This is a no-op but will be used in upcoming scudo changes that allow to
change the depot size at process startup time, and as such we will no
longer be able to call __scudo_get_stack_depot_size in debuggerd.
We already did the equivalent change for the ring buffer size in
https://r.android.com/q/topic:%22scudo_ring_buffer_size%22
Bug: 309446692
Change-Id: Icdcf4cd0a3a486d1ea07a8c616cae776730e1047
Symlinks were previously able to escape the genrule sandbox, but
after aosp/2850015 they can't.
Instead of a symlink, just use the fs_config_generator soong module.
Bug: 307824623
Test: generated_android_ids
Change-Id: Ifcd9eb06c46181903ff57713132940939d5facf6
No-one's hit this in practice, that I know of, but there are very few
instances of this old workaround for kernel/userspace mismatches still
present, and (as part of the much harder and less effective `struct
sigaction` cleanup), we should just remove them.
Bug: http://b/236042740
Test: treehugger
Change-Id: I6c71d4353044cf57cfa8a9796a4c3d6a4d51cd86
Before this change, we have the kernel's sigaction in the uapi headers,
and our own sigaction in <bits/signal_types.h> and we rely on callers
making sure to use `#define` to move the kernel type out of the way if
they include a uapi header directly. This is obviously error-prone and
undesireable, and not what we usually do now.
What we _usually_ do now is use the header scrubber's ability to replace
a struct definition with a `#include <bits/STRUCT.h>`, but that doesn't
work here because struct sigaction relies on a lot of other types,
some of which also come from uapi headers.
So instead use our second best trick, which is to "move the kernel struct
out of the way" at header scrubbing time instead. This means that someone
who does `#include <linux/signal.h>` or `#include <asm/signal.h>` won't
get `struct sigaction` (they'll only have `struct __kernel_sigaction`
instead), but it does mean that they can't get two incompatible
definitions if they include a uapi header both directly and indirectly.
So although this doesn't do what I'd set out to do, it's still an
improvement in some cases, and it's our preferred idiom in most cases
anyway. (I'll come back once this is in to tidy up the two other kernel
structs where we're still using the deprecated "rename out of the way
using #define" trick, but this change is already hairy enough, and
there's a possibility it will break code that didn't care that it was
getting the kernel `struct sigaction` rather than the userspace one.)
Bug: http://b/236042740
Test: treehugger
Change-Id: Icff50e330c09c587e8f77ba0fb7cffffd9c3b708
We'll probably never hit this (because the case I hit it with, struct
sigaction, isn't amenable to the "replace with #include <bits/STRUCT.h>"
trick), but in case we do, and because a set expresses our intent better
than a list, keep the list^Wset of generated includes in a set.
Bug: http://b/236042740
Test: treehugger
Change-Id: I21f5c08515eab1b28e6a36fc00149b6bc7740b7e
Adding the new option log_allocator_stats_on_signal that will call
mallopt(M_LOG_STATS, 0), when a signal is sent to a process.
This call does not happen in the signal handler, but a variable
is set to trigger the mallopt call. The next time any allocation
call occurs, the mallopt call will be made.
Also, includes new unit tests for the new config option.
Test: All unit tests pass.
Test: Enabling the new feature and stop/start and sending the signal to
Test: a process and observing the log contains the memory stats.
Test: Did the above for a scudo and jemalloc based device.
Change-Id: Idcf6fca74036efb065b9c4cc037aaf9bcf0f139e
This patch adds the necessary bionic code for the linker to protect
global data using MTE.
The implementation is described in the MemtagABI addendum to the
AArch64 ELF ABI:
https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst
In summary, this patch includes:
1. When MTE globals is requested, the linker maps writable SHF_ALLOC
sections as anonymous pages with PROT_MTE (copying the file contents
into the anonymous mapping), rather than using a file-backed private
mapping. This is required as file-based mappings are not necessarily
backed by the kernel with tag-capable memory. For sections already
mapped by the kernel when the linker is invoked via. PT_INTERP, we
unmap the contents, remap a PROT_MTE+anonymous mapping in its place,
and re-load the file contents from disk.
2. When MTE globals is requested, the linker tags areas of global memory
(as defined in SHT_AARCH64_MEMTAG_GLOBALS_DYNAMIC) with random tags,
but ensuring that adjacent globals are never tagged using the same
memory tag (to provide detemrinistic overflow detection).
3. Changes to RELATIVE, ABS64, and GLOB_DAT relocations to load and
store tags in the right places. This ensures that the address tags are
materialized into the GOT entries as well. These changes are a
functional no-op to existing binaries and/or non-MTE capable hardware.
Bug: N/A
Test: atest bionic-unit-tests CtsBionicTestCases --test-filter=*Memtag*
Change-Id: Id7b1a925339b14949d5a8f607dd86928624bda0e
The NDK no longer includes gold, so static binaries built by the NDK no
longer need to support gold.
Test: bionic static unit tests
Change-Id: Idddcb9eb18921acfc1ae2a3c755592a5ab30290a
Both glibc/musl's and Apple's <string.h> drags in <strings.h> in most
cases. So do the BSDs. Given so much historic precedent (often accompanied
by comments saying "POSIX made us move this stuff out into another
file, but we don't want to break existing code [from the 1980s]"!), plus
the fact that someone hit this in practice, trying to build one of the
linux selftests against bionic, let's change bionic over too...
Bug: http://b/310035365
Test: treehugger
Change-Id: I8f13d82fe3d3df71a656641a725410acdfd97465
Right now, the unwinder doesn't support compressed sections, so unwinds
through the 32 bit libc.so don't work. It will be supported very soon,
but even then, it will be slower to use, so make sure the debug_frame
is not compressed at all.
Bug: 309857311
Test: 32 bit debuggerd unit tests pass.
Test: 32 bit unwind unit tests pass.
Change-Id: Ic8bec1d275c629ec43051bbe912014f281450eda
Adding the slot to store pointer to the guest state
for natively translated environment.
Test: run bionic unit tests on redfin
Bug: http://b/293142668
Change-Id: I4fea5595fb613f37c85cd2b591cbcd15313973c1
There are a lot of bugs about this over the years, too many to
reference here. Though, I referenced b/176065420 to understand
exactly why it's problematic and what the future direction may
be.
Fixes: 307859642
Test: N/A
Change-Id: Ida31fe622309a7f9b2cd55e5bbb3569fc5aded0e
This came up in a man-pages discussion. I've left the ones that take an
integer to say what _units_ they sleep in, but the ones that take a
struct seem clearest if they just say "duration".
Test: treehugger
Change-Id: I13e39855a9d2c49e1653ec2263cb09c9f239254d
The android_unsafe_frame_pointer_chase keeps going even when a
frame is 0. Modify the unwind to stop when this case is found.
I found this while running the GwpAsanCrasherTest.run_gwp_asan_test
from debuggerd_test and printing the tombstone created. The
deallocated by and allocated by stack traces always ended in 0 frame.
After fixing this, the last 0 frame is no longer present.
Test: Ran the debuggerd test and printed the tombstone on a raven
Test: verifying that the last frame is non-zero.
Test: Ran the bionic unit tests.
Change-Id: I8d64679277abcf5f237e6759051db11ffaa34c2f
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.6
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: Ib5ff5a23f382721d98d1e428a295c6794b190d8d
Investigation revealed that the vector instructions in the assembly
implementation of memcmp seem to be putting QEMU into a bad state. This
code sometimes results in a SIGILL.
Temporarily disable the vector instructions for just this function.
Bug: 306514350
Test: Verified boot on AOSP CF image.
Change-Id: I184762354092b4b500c78a29a10db18cef0dab90
The bionic benchmarks set the decay time in various ways, but
don't necessarily restore it properly. Add a new method for
getting the current decay time and then a way to restore it.
Right now the assumption is that the decay time defaults to zero,
but in the near future that assumption might be incorrect. Therefore
using this method will future proof the code.
Bug: 302212507
Test: Unit tests pass for both static and dynamic executables.
Test: Ran bionic benchmarks that were modified.
Change-Id: Ia77ff9ffee3081c5c1c02cb4309880f33b284e82
Rather than do the work to fix the ODR violations while preserving non-V,
let's just remove the non-V code. Android will require V anyway, and
anyone trying to work on a non-V system in the meantime already needs
a bunch of patches to the build system and ART, so one more shouldn't
hurt too much.
Test: treehugger
Change-Id: Iab43d8a80d99a4d045b0008dbea4e7e8696d1167
We were copying the data fine, but the return value was one vector
length too far (but also not taking into account the actual number of
bytes in the last transfer).
Also move the stpcpy() tests to EXPECT_EQ() so we get all the details
of the failure at once.
Test: treehugger
Change-Id: I76bf02c8a31f40722acb7c9fd8e301d50e405bf8
The zygote cannot have visiblity to LIBC_PLATFORM methods. Therefore,
move __system_properties_reload to LIBC, and rename it
__system_properties_zygote_reload, and indicate in comments that it
should not be used by non-zygote apps
Bug: 291814949
Test: atest CtsBionicRootTestCases
Change-Id: Iee8fa0c76b740543c05a433393f2f4bef36d6d3d
Create a second set of system properties, that can be overlaid over the
real ones if necessary, for appcompat purposes.
Bug: 291814949
Ignore-AOSP-First: Aosp -> internal merge conflict
Test: manual, treehugger, system_properties_test
Change-Id: I541d3658cab7753c16970957c6ab4fc8bd68d8f3
Merged-In: I884a78b67679c1f0b90a6c0159b17ab007f8cc60
Create a second set of system properties, that can be overlaid over the
real ones if necessary, for appcompat purposes.
Bug: 291814949
Ignore-AOSP-First: Aosp -> internal merge conflict
Test: manual, treehugger, system_properties_test
Change-Id: I884a78b67679c1f0b90a6c0159b17ab007f8cc60
Add test for aosp/2792161
Bug: 297317502
Test: cpp.py
Change-Id: I2eadd3b9371ec2f8b8c24107888cad5e3ae26f60
Signed-off-by: Edward Liaw <edliaw@google.com>
replaceTokens was only replacing tokens for cpp name clashes in the
macro body. This change will also replace tokens in the arguments.
Bug: 297317502
Test: bionic/libc/kernel/tools/update_all.py
Change-Id: I102d000a8a4cea507b00c867df2a16106d8aed89
Signed-off-by: Edward Liaw <edliaw@google.com>
Adds support for the dynamic entries to specify MTE enablement. This is
now the preferred way for dynamically linked executables to specify to
the loader what mode MTE should be in, and whether stack MTE should be
enabled. In future, this is also needed for MTE globals support.
Leave the existing ELF note parsing as a backup option because dynamic
entries are not supported for fully static executables, and there's
still a bunch of glue sitting around in the build system and tests that
explicitly include the note. When -fsanitize=memtag* is specified, lld
will create the note implicitly (along with the new dynamic entries),
but at some point once we've cleaned up all the old references to the
note, we can remove the notegen from lld.
Bug: N/A
Test: atest bionic-unit-tests CtsBionicTestCases --test-filter=*Memtag*
Test: Build/boot the device under _fullmte.
Change-Id: I954b7e78afa5ff4274a3948b968cfad8eba94d88
We were keeping the macros that call this function, but not the function
itself. That's not helpful.
Bug: http://b/297317502
Test: treehugger
Change-Id: Icf8f734a129fe73ec740bb7cfbb11deb01a98cb3
The first app developer (we know of) that hit this didn't understand
what it was trying to tell them.
Before:
FORTIFY: fcntl(F_SETFD) passed non-FD_CLOEXEC flag: 0x801
After:
FORTIFY: fcntl(F_SETFD) only supports FD_CLOEXEC but was passed 0x801
Bug: https://issuetracker.google.com/304348746
Test: treehugger
Change-Id: I8522e851d8f74c91152ebae68b083b5272d49255
"""
__swsetup: set error flag and errno on error.
Previously, we set errno to EBADF if the cantwrite() macro (which calls
__swsetup()) returns true for POSIX compliance. However, we neglected
to also set the error flag, __SERR. Rather than set the error flag in
all callers of cantwrite(), set both errno and the error flag in
__swsetup(). This matches what FreeBSD does and makes it possible
to choose a proper errno value for the second error condition in
__swsetup(). OK deraadt@
"""
fc99cf9338
Bug: http://b/302742247
Test: treehugger
Change-Id: If3be4905fc21e513cb8718cca671eae3885e411a
The code comment that's being removed here defends the old
implementation by claiming that it's faster. Annoyingly, we don't know
what hardware that was run on. Running on current-ish hardware
(cheetah), I can't really tell the difference except: (a) for hwasan,
avoiding the unsafe memory access by _not_ using the array is a huge
win, and (b) even for arm32 the logic is (very slightly) faster than the
array lookup.
So let's get rid of the unsafety (as musl and FreeBSD have already done)
and the large hwasan slowdown (10ns vs 2ns). It's possible in-order
cores might still care, but it's 2023 and it's time to move on.
This change _does not_ remove `_ctype_` and associated macros from the
headers, though we might want to come back and do that. Historically
libc++ used these implementation details directly, but that's no longer
the case, and it seems unlikely that anyone else is, and today's results
suggest they probably shouldn't anyway, and doing so only ever really
made sense for something like ISO-Latin-1 anyway. Most ASCII tests are
_always_ better off inlined, and Android's never supported non-ASCII for
<ctype.h> anyway (use the isw*() functions if you want that, but bear in
mind that if you're actually dealing with human languages, you probably
want icu4c rather than libc anyway).
Test: treehugger & benchmarks
Change-Id: Ifac25c23ac33e996a3c726317b5c6e602dc72e30
The NDK only supports API 21 and later, so we don't need to worry
about older API levels any more.
All the functions in this file are trivial, being but a single
instruction on most architectures. For that reason, we inline them by
default. (We continue to also provide actual symbols for any caller
that needs them --- in particular existing binaries!)
Also inline all the _l() variants too. No-one should be using them,
but since we're already using trickery to only implement the non-_l()
variants once, we may as well use the same trick for both.
Test: treehugger
Change-Id: I17637c49dd14be9e5ecb8246e72e8acc662739f1
