When implemented using fcpyd, Clang sometimes generates redundant vmovs
after SET_FREGS on ARM32 and touches registers set, causing the test to
fail. Use vmov.f64 instead and that avoids the issue.
Test: atest CtsBionicTestCases:setjmp#setjmp_fp_registers -- --abi armeabi-v7a
Test: atest CtsBionicTestCases:setjmp#setjmp_fp_registers -- --abi arm64-v8a
Bug: 337903801
Change-Id: Ibd89b120f8a3cc80c34905069469fd244a902d1e
On HWASan, it's not really possible to test scribbling on the
stack protector, so skip the test in this case.
Bug: 339529777
Test: Verified stack protector test is skipped.
Change-Id: I541416f8a84f649f83868574907b1e445d990aa0
The previous names were difficult to decipher. Now, let's change this
all to be more clear as it's actually one android_mallopt() call
depending on where it's called from, rather than the intended behaviour.
Also updated the comments so it's clear what happened across different
versions of Android.
Test: atest bionic-unit-tests CtsGwpAsanTestCases
Bug: N/a
Change-Id: I0582cab0b74aa09f4af54f9fbe5ba22697f82082
The optional block size for the /proc filesystem is set to page size.
The tests must reflect the same.
Bug: 315510913
Change-Id: Ifccf833829b4ea4ff9c7d375208124cdc43af04a
LINE_MAX is a bad idea from the 1970s that we've ignored until now,
but there's already one hack in the AOSP tree (external/ltp) to work
around its absence, and kselftests would need another. Both uses are
bad code, but bad code exists, and iOS/macOS and musl/glibc all have
the same 2048 value, and it is in POSIX, so at least it's consistent
idiocy. Hopefully we're not encouraging more of it!
Bug: https://github.com/llvm/llvm-project/issues/88119
Change-Id: Ief219c3fe20b3d95da7040c4b9411f997b1c0470
arm32/arm64: Previously, the loader miscalculated a negative value for
offset_bionic_tcb_ when the executable's alignment was greater than
(8 * sizeof(void*)). The process then tended to crash.
riscv: Previously, the loader didn't propagate the p_align field of the
PT_TLS segment into StaticTlsLayout::alignment_, so high alignment
values were ignored.
__bionic_check_tls_alignment: Stop capping alignment at page_size().
There is no need to cap it, and the uncapped value is necessary for
correctly positioning the TLS segment relative to the thread pointer
(TP) for ARM and x86. The uncapped value is now used for computing
static TLS layout, but only a page of alignment is actually provided:
* static TLS: __allocate_thread_mapping uses mmap, which provides only
a page's worth of alignment
* dynamic TLS: BionicAllocator::memalign caps align to page_size()
* There were no callers to StaticTlsLayout::alignment(), so remove it.
Allow PT_TLS.p_align to be 0: quietly convert it to 1.
For static TLS, ensure that the address of a TLS block is congruent to
p_vaddr, modulo p_align. That is, ensure this formula holds:
(&tls_block % p_align) == (p_vaddr % p_align)
For dynamic TLS, a TLS block is still allocated congruent to 0 modulo
p_align. Fixing dynamic TLS congruence is mostly a separate problem
from fixing static TLS congruence, and requires changing the dynamic
TLS allocator and/or DTV structure, so it should be fixed in a
later follow-up commit.
Typically (p_vaddr % p_align) is zero, but it's currently possible to
get a non-zero value with LLD: when .tbss has greater than page
alignment, but .tdata does not, LLD can produce a TLS segment where
(p_vaddr % p_align) is non-zero. LLD calculates TP offsets assuming
the loader will align the segment using (p_vaddr % p_align).
Previously, Bionic and LLD disagreed on the offsets from the TP to
the executable's TLS variables.
Add unit tests for StaticTlsLayout in bionic-unit-tests-static.
See also:
* https://github.com/llvm/llvm-project/issues/40872
* https://sourceware.org/bugzilla/show_bug.cgi?id=24606
* https://reviews.llvm.org/D61824
* https://reviews.freebsd.org/D31538
Bug: http://b/133354825
Bug: http://b/328844725
Bug: http://b/328844839
Test: bionic-unit-tests bionic-unit-tests-static
Change-Id: I8850c32ff742a45d3450d8fc39075c10a1e11000
We're still copy & pasting this workaround about, but the bug was supposedly fixed years ago!
Bug: http://b/34945607
Bug: http://b/33942619
Bug: http://b/34195559
Change-Id: Icf3d184d2ddb447dff7dacccea1dc903da816505
It's usually more helpful to see all the output so far.
If we're worried about fflush() failing because of the state we're in, we shouldn't be using stdio at all!
If this _does_ become a problem, we should probably switch to using the internal functions: `__assert2` for bionic, `__assert_fail` for musl/glibc, and `__assert_rtn` for macOS.
Unfortunately although `__assert2` and `__assert_fail` take the same arguments, they're in a different order, so we can't simply add a symbol alias to make that difference go away, and it's not clear that there's enough value to adding an otherwise unused symbol.
Change-Id: I653183737ab6368890bbd9d0e2f37fc5cb2e1dec
Split the test out into a separate executable to reduce the number of
ELF modules in the DTV, so that the test can more easily observe the
behavior of loading a module that requires doubling the DTV size. We
want to see the DTV expand from 5 entries (8 words w/header) to
13 entries (16 words w/header).
Make the test work with an initial number of ELF TLS modules between
2 and 4.
Bug: http://b/175635923
Test: bionic-unit-tests
Change-Id: I1e91b4462987a5c80e13838669c359053f5a62f6
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
