When the page_size < p_align of the ELF load segment, the loader
will end up creating extra PROT_NONE gap VMA mappings between the
LOAD segments. This problem is exacerbated by Android's zygote
model, where the number of loaded .so's can lead to ~30MB increase
in vm_area_struct unreclaimable slab memory.
Extend the LOAD segment VMA's to cover the range between the
segment's end and the start of the next segment, being careful
to avoid touching regions of the extended mapping where the offset
would overrun the size of the file. This avoids the loader
creating an additional gap VMA for each LOAD segment.
Consider a system with 4KB page size and the ELF files with 64K
alignment. e.g:
$ readelf -Wl /system/lib64/bootstrap/libc.so | grep 'Type\|LOAD'
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0441a8 0x0441a8 R 0x10000
LOAD 0x0441b0 0x00000000000541b0 0x00000000000541b0 0x091860 0x091860 R E 0x10000
LOAD 0x0d5a10 0x00000000000f5a10 0x00000000000f5a10 0x003d40 0x003d40 RW 0x10000
LOAD 0x0d9760 0x0000000000109760 0x0000000000109760 0x0005c0 0x459844 RW 0x10000
Before this patch:
$ cat /proc/1/maps | grep -A1 libc.so
7fa1d4a90000-7fa1d4ad5000 r--p 00000000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4ad5000-7fa1d4ae4000 ---p 00000000 00:00 0
7fa1d4ae4000-7fa1d4b76000 r-xp 00044000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4b76000-7fa1d4b85000 ---p 00000000 00:00 0
7fa1d4b85000-7fa1d4b8a000 r--p 000d5000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4b8a000-7fa1d4b99000 ---p 00000000 00:00 0
7fa1d4b99000-7fa1d4b9a000 rw-p 000d9000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4b9a000-7fa1d4feb000 rw-p 00000000 00:00 0 [anon:.bss]
3 additional PROT_NONE (---p) VMAs for gap mappings.
After this patch:
$ cat /proc/1/maps | grep -A1 libc.so
7f468f069000-7f468f0bd000 r--p 00000000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f0bd000-7f468f15e000 r-xp 00044000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f15e000-7f468f163000 r--p 000d5000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f163000-7f468f172000 rw-p 000da000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f172000-7f468f173000 rw-p 000d9000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f173000-7f468f5c4000 rw-p 00000000 00:00 0 [anon:.bss]
No additional gap VMAs. However notice there is an extra RW VMA at
offset 0x000da000. This is caused by the RO protection of the
GNU_RELRO segment, which causes the extended RW VMA to split.
The GNU_RELRO protection extension is handled in the subsequent
patch in this series.
Bug: 316403210
Bug: 300367402
Bug: 307803052
Bug: 312550202
Test: atest -c linker-unit-tests
Test: atest -c bionic-unit-tests
Change-Id: I7150ed22af0723cc0b2d326c046e4e4a8b56ad09
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
After updating libc++, the demangled output's float literal ends with
'L' and the <template-args> ends with a '>'. However, the input is
invalid, so the demangler probably should return nullptr.
Bug: http://b/175635923
Test: bionic-unit-tests
Change-Id: I8440118e4f5791a3464e15d6f9d2f5f3d006e54d
The -1 from pathconf()/fpathconf() with these isn't the "I don't know
what you're talking about" -1/EINVAL, but the "I understand the
question, but don't have an answer for you --- you'll have to try it and
see" -1.
Bug: http://b/326245682
Test: treehugger
Change-Id: I67be277f3ffd9b5a355787ae7ffc4a31e32b0128
The 2024Q builds don't have their own branches like QPR builds used to,
and there's no API bump until V proper, so the same CTS build needs to
cope with both last year's Android release _and_ the one that doesn't
have an API level yet. So poke holes in the uid test to support these
mismatches.
This runs the risk of allowing accidental misuse in U of the very uids
that will definitely be used in V, so check that _if_ the uids do exist,
they have the names we're expecting them to have. That should make
accidents easier to spot?
Bug: http://b/322256445
Test: treehugger
Change-Id: I3b24b8fafe20012df70c73589b40dba5a10e50e9
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
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
When the page_size < p_align of the ELF load segment, the loader
will end up creating extra PROT_NONE gap VMA mappings between the
LOAD segments. This problem is exacerbated by Android's zygote
model, where the number of loaded .so's can lead to ~30MB increase
in vm_area_struct unreclaimable slab memory.
Extend the LOAD segment VMA's to cover the range between the
segment's end and the start of the next segment, being careful
to avoid touching regions of the extended mapping where the offset
would overrun the size of the file. This avoids the loader
creating an additional gap VMA for each LOAD segment.
Consider a system with 4KB page size and the ELF files with 64K
alignment. e.g:
$ readelf -Wl /system/lib64/bootstrap/libc.so | grep 'Type\|LOAD'
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0441a8 0x0441a8 R 0x10000
LOAD 0x0441b0 0x00000000000541b0 0x00000000000541b0 0x091860 0x091860 R E 0x10000
LOAD 0x0d5a10 0x00000000000f5a10 0x00000000000f5a10 0x003d40 0x003d40 RW 0x10000
LOAD 0x0d9760 0x0000000000109760 0x0000000000109760 0x0005c0 0x459844 RW 0x10000
Before this patch:
$ cat /proc/1/maps | grep -A1 libc.so
7fa1d4a90000-7fa1d4ad5000 r--p 00000000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4ad5000-7fa1d4ae4000 ---p 00000000 00:00 0
7fa1d4ae4000-7fa1d4b76000 r-xp 00044000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4b76000-7fa1d4b85000 ---p 00000000 00:00 0
7fa1d4b85000-7fa1d4b8a000 r--p 000d5000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4b8a000-7fa1d4b99000 ---p 00000000 00:00 0
7fa1d4b99000-7fa1d4b9a000 rw-p 000d9000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7fa1d4b9a000-7fa1d4feb000 rw-p 00000000 00:00 0 [anon:.bss]
3 additional PROT_NONE (---p) VMAs for gap mappings.
After this patch:
$ cat /proc/1/maps | grep -A1 libc.so
7f468f069000-7f468f0bd000 r--p 00000000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f0bd000-7f468f15e000 r-xp 00044000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f15e000-7f468f163000 r--p 000d5000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f163000-7f468f172000 rw-p 000da000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f172000-7f468f173000 rw-p 000d9000 fe:09 20635520 /system/lib64/bootstrap/libc.so
7f468f173000-7f468f5c4000 rw-p 00000000 00:00 0 [anon:.bss]
No additional gap VMAs. However notice there is an extra RW VMA at
offset 0x000da000. This is caused by the RO protection of the
GNU_RELRO segment, which causes the extended RW VMA to split.
The GNU_RELRO protection extension is handled in the subsequent
patch in this series.
Bug: 316403210
Bug: 300367402
Bug: 307803052
Bug: 312550202
Test: atest -c linker-unit-tests [Later patch]
Test: atest -c bionic-unit-tests
Change-Id: I3363172c02d5a4e2b2a39c44809e433a4716bc45
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
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
The libcs we use don't need these any more (if they ever did), and we
were setting these globally in the build system anyway.
Also remove the -D_LIBCPP_ENABLE_CXX17_REMOVED_BINDERS from versioner
which doesn't seem needed any more either.
Test: treehugger
Change-Id: I9fb225b085906a02918c5847401d6c59f7779581
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
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I0a63faa8ca359592a29d7bca1a40ecd94fd50044
(cherry picked from commit 7506c37386)
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
(This is the sys_vfs_test equivalent of the earlier change made to
sys_statvfs_test.)
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I3c6f784d1e348bf1be3a102d1dd6336c33d0b2db
(cherry picked from commit 1b48afbc66)
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
(This is the sys_vfs_test equivalent of the earlier change made to
sys_statvfs_test.)
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I3c6f784d1e348bf1be3a102d1dd6336c33d0b2db
Obviously stack MTE conflates with the stack protector test. It doesn't
conflate with heap MTE (which we're expecting to push more broadly as
part of the -eng build), and so we want to keep this test working under
heap-mte scenarios as well.
Hence, the check-if-stack-variable-is-tagged test, and only under that
case, we skip.
Test: atest bionic-unit-tests on a fullmte device (with stack MTE turned
back on and the new compiler).
Bug: 320448268
Change-Id: I2ecee8a7c46416883235bf5c4ee2de9408047829
This reverts commit 4c5eeb8346 in main,
where we have the newer tzcode and so can pass the stricter test.
Bug: http://b/307680874
Test: treehugger
Change-Id: I28a6f423815655a59fb503230e50a7b618b0349a
As long as 2024Q1 is using Android 14's CTS, Android 14's CTS needs to
work with both. That doesn't make much sense for this test of a bug fix,
so just disable it.
Bug: http://b/307680874
Test: treehugger
Change-Id: Ic1bea5d0404c91279a025ac97b521f07e4d2d387
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
Bug: http://b/319590754
Test: treehugger
Change-Id: I0a63faa8ca359592a29d7bca1a40ecd94fd50044
gtest's Message class has a special handler for operator<< of wchar_t*
to convert it to UTF-8, but it doesn't have one for a single wchar_t or
for a char16_t* string. It delegates these to std::stringstream, which
as of a libc++ upgrade, deletes its operator<< for char16_t and
wchar_t. See wg21.link/p1423r3.
Bug: http://b/175635923
Test: m MODULES-IN-bionic
Change-Id: I8307663b72855cfc0b91d7f63993f1f6fe028b8e
What's important is that we name the flag. It doesn't really matter
whether you have the better message that will be in Android 15. As long
as 2024Q1 is using Android 14's CTS, Android 14's CTS needs to work with
both.
Bug: http://b/307680874
Test: treehugger
Change-Id: I8c50707e1dfd6b40e6ced887ae105508c6339989
As long as 2024Q1 is using Android 14's CTS, Android 14's CTS needs
to work with both. That doesn't really seem practical for these tests,
so just disable them.
Bug: http://b/307680874
Test: treehugger
Change-Id: Iab4085ce1be1b0e00a6714eaf3008787e29e7e7b
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
We've updated the corresponding glibc headers so we don't need these
hacks any more.
Bug: http://b/318541070
Test: treehugger
Change-Id: Ic1974f30f9edb2589cc93041822706bc89909882
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
Benchmark added to test an optimization I'll send round next, test added
when an even bigger refactoring (as part of a more interesting
optimization) broke strtol() in a way the strtol() tests didn't notice.
Test: treehugger
Change-Id: Ic974900021107938dbbbe98648960adb102d9595
The sysconf_SC_ARG_MAX test was failing because it didn't
handle the case for 16k. After fixing the test case, it will
handle 4k/16k page sizes and fail when there is another page
size.
Bug: 315174209
Test: atest -c bionic-unit-tests-static
Change-Id: Ie24a79be9d6790a1243be48d39f67acda485c37d
These were added because the tests wouldn't build without them, but they
do now.
Bug: http://b/132640749
Test: treehugger
Change-Id: Idc0aff08ce461bde5ed2cd816f04dcdef5d7af5d
