This reverts commit 12b2042a3f.
Reason for revert: Droidmonitor triggered revert due to build breakage in b/342029467. Will be verifying through ABTD before submission.
Change-Id: I801b4999047732b86985f0be2f4aae90b9998e4a
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
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>
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
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
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
These were added because the tests wouldn't build without them, but they
do now.
Bug: http://b/132640749
Test: treehugger
Change-Id: Idc0aff08ce461bde5ed2cd816f04dcdef5d7af5d
This is now the default.
I've left the fuzzer workaround in for now, but we can come back and see
whether the fuzzer library has actually switched.
Test: treehugger
Change-Id: Ia3a09738396bfe915ceabec4a6019f4cedb0f39c
This test comes in two flavours: a prebuilt, and one from source (which is used
to generate the prebuilt). For now, the in-tree prebuilt compiler isn't
new enough to actually build binaries with proper MTE globals support,
so I've provided prebuilts using a tip-of-tree compiler. Thus, the MTE
globals support in the linker can be experimented on, tested, and
(hopefully) submitted while not being blocked on the toolchain roll.
You can see the binaries have MTE globals by grabbing a tip-of-tree
compiler, and running 'llvm-readelf --memtag <bin>'.
Bug: N/A
Test: atest bionic-unit-tests --test-filter=*Memtag*
Change-Id: I2fc4fc9d1c6ddd16c2204dd728d4ebe463928522
A clang update enabled -Wreorder-init-list by default. Since it doesn't
provide any benefit to the bionic code, disable the warning.
Test: Builds without warnings.
Change-Id: I5891527ef532b59dc2a02b39a5896112411d21f5
This list has diverged between cts/ and bionic/. Instead of having to
maintain the list, let's just make cts/ inherit the one from bionic.
Bug: 296832150
Test: atest bionic-unit-tests CtsBionicTestCases
Change-Id: I271668e83aed239107b9129dfb707f03bae47cfa
The obsolete mips header rides again!
The most interesting part of this change is that I've removed the hack
that meant that all system call wrappers starting with `__` defaulted to
being hidden symbols. That's no longer useful given our linker scripts,
and it actively got in the way here because the public libc symbol
actually starts with `__` in glibc, and it would be weird and annoying
for developers if we chose a different name.
Test: strace
Change-Id: I230479787895e8e34f566ade36346a8241eea998
Discussion of this during my recent minor cleanup convinced me that we
should just remove __RENAME_LDBL. There's no obvious benefit to being
able to build something for 32-bit if you can't build the same code for
64-bit, given that most new hardware (and entire verticals such as Auto)
are 64-bit-only, and the Play Store requires any app with 32-bit code to
also ship 64-bit code.
Test: treehugger
Change-Id: I1c5503b968ca66925d7bd125bd3630c41ec1bfd0
This is the one openlog() flag that toybox uses. We should probably try
to unify toybox's POSIX logger and Android-specific log at some point,
and this will help.
Also fix our behavior with an empty format string, noticed while adding
tests.
Test: treehugger
Test: adb shell logger -s foo
Change-Id: Ic027e78a460be3db83cc4c6f9946c9efa22be6e1
Musl #defines utmp to utmpx, which causes the tests in utmp_test.cpp
to collide with the ones in utmpx_test.cpp. Skip the utmp_test.cpp
when building for musl.
Test: m USE_HOST_MUSL=true
Change-Id: Ie05ddf6e1fd8c3bcc687d2537c19b6ab70ab8d67
This mode instructs the linker to search for libraries in hwasan
subdirectories of all library search paths. This is set up to contain a
hwasan-enabled copy of libc, which is needed for HWASan programs to
operate. There are two ways this mode can be enabled:
* for native binaries, by using the linker_hwasan64 symlink as its
interpreter
* for apps: by setting the LD_HWASAN environment variable in wrap.sh
Bug: 276930343
Change-Id: I0f4117a50091616f26947fbe37a28ee573b97ad0
Now <utmpx.h> isn't any more useful on Android than <utmp.h> is, but it
is POSIX, and -- importantly -- we can implement it with just a header
file, so code can use it on every existing API level.
macOS does indeed only have the <utmpx.h> functions (although it does
still have the <utmp.h> header!), so potentially portable code might
want <utmpx.h> on Android. (glibc/musl both have both headers.)
Bug: https://github.com/landley/toybox/pull/213
Test: treehugger
Change-Id: Iaa88167708182009a63e2e1a15f11186b251ed02
