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
Add support for 16kb page sizes in the test cases: page_start
and page_offset.
Bug: 315174209
Test: atest -c linker-unit-tests
Change-Id: Ibaae493a0930f3f2df390a6af6c8a988a682fe52
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
Calling free() during system property init results in premature
allocator initialization. This has been fixed with a Scudo change in
https://r.android.com/2853684. This patch extends MemtagNoteTest to
verify that there are no stray PROT_MTE mappings when MTE is not
enabled in the binary.
Test: adb shell setprop arm64.memtag.bootctl memtag
adb reboot
bionic-unit-tests --gtest_filter=MemtagNoteTest.SEGV/*
Bug: 309698651
Change-Id: I6c7733d8799537d898c97b00d494ce6591cf44d9
This reverts commit f71ee5adb7.
Reason for revert: linker crash in soinfo::apply_relr_reloc
Bug: 314038442
Change-Id: Ib2415519e37d6b2acb30f50afa6c45391e2a4b70
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
The build breakage is now fixed by the current stable Clang, workaround
is no longer needed.
Test: presubmit
Bug: 169004486
Change-Id: Id8df8efeb9f4183921cbf75f1c51b1507bff1eb0
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
The build breakage is now fixed by the current stable Clang, workaround
is no longer needed.
Test: presubmit
Change-Id: Ice2863844ff886f503d50fa7a006cde78d16492d
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 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
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
