Bug: 137795072
Test: Built using jemalloc, and verified that the two processes that
Test: use libc_scudo do not crash.
Change-Id: Icf773b656d7e2bcdf41b4979e9b6cd980b02d34d
When the heapprofd lazy-initialization dispatch table is installed, two
threads can call malloc() at the same time. One will do the
lazy-initialization, the other will fail the atomic_exchange of
gHeapprofdInitHookInstalled and go to system malloc. The system malloc
still contains the lazy-init malloc, and will recurse.
Fix it so the second thread goes directly to the previous dispatch
table, or to the system allocator directly (instead of through libc
malloc()).
Bug: 150085813
Test: atest perfetto_integrationtests
Test: TracedPerfCtsTest.SystemWideDebuggableApp on cuttlefish x86.
Change-Id: Ia85ad619a0d5e3f558136d84c34dbada4e8b845d
The values of some constants have changed, and the tag mask has changed from
being an exclusion mask to an inclusion mask.
Bug: 135772972
Change-Id: I322fceae7003bee6b391e7187194ed4c0cb28c58
If an alternate signal stack is set and the frame record is in bounds of
that stack, we need to use the top of the alternate signal stack for bounds
checking rather than the normal stack.
Bug: 150215618
Change-Id: I78b760d61b27da44f8e0cfee3fe94a791011fe58
To prevent unnecessary SELinux denials, the check referred to by the
comment is kept in place. This allows us to keep auditing the
SELinux denial in order to catch apps that intentionally send
RTM_GETLINK messages.
Fix: 141455849
Test: atest bionic-unit-tests-static
Test: atest NetworkInterfaceTest
Change-Id: I41e5ad6f071c820a8246177a0c629b3be788a942
This change adds standard branch protection to bionic unit tests
for arm64 targets. For more information see
https://developer.arm.com/search#q=branch-protection
Both Armv8.3-A Pointer Authentication (using the A-key) hint-space
instructions and Armv8.5-A Branch Target Identification hint-space
landing pads are added to the generated code.
Test: 1. Tested on flame
2. Tested on FVP
Change-Id: Ice991c538a9101448dea64c357f3f6bfb93877eb
Stubs of version 29 should be provided to those APEX modules targeting
previous SDK release.
Bug: 145796956
Test: m
Change-Id: I9454fbf81377aba25e75a6fdfc77cbb070eaadde
Heapprofd uses an ephemeral dispatch table to ensure that GWP-ASan can
be called during heapprofd initialization. Previously, we grabbed the
backup dispatch table from the globals, which is wrong if GWP-ASan isn't
installed (as the malloc_dispatch_table is linker-initialised and not
set to a known good value if a malloc hooker isn't used).
Instead, grab the correct ephemeral dispatch table. When GWP-ASan is
installed, use a copy of its table as the dispatch. When nothing is
installed, fall back to using the native allocator dispatch.
Bug: 135634846
Bug: 150085813
Test: atest perfetto_integrationtests
Test: TracedPerfCtsTest.SystemWideDebuggableApp on cuttlefish x86.
Change-Id: I4beaf9192acadbe00adc02de2e0b0aab6f7a2190
This includes optimized strrchr and strchrnul routines, and an MTE-compatible
strlen routine.
Bug: 135772972
Change-Id: I48499f757cdc6d3e77e5649123d45b17dfa3c6b0
This is a best-effort mitigation for potential crashes when the
profiling signal handler is triggered within certain secomp'd processes.
In particular, we're working around cases where the seccomp policy
doesn't allow some of the handler syscalls, and has a crashing
disposition towards violations via SECCOMP_RET_TRAP, plus a crashing
SIGSYS handler. While not general, this covers the configurations seen
in practice on Android (which are all using minijail in the same way).
By overriding the SIGSYS handling for the duration of the profiling
handler, we can instead receive such SIGSYS signals, and instead recover
from them in a non-crashing manner (the handler is responsible for
filling the syscall return register, since the syscall itself was
skipped).
For simplicity, we're swallowing all SIGSYS signals during this window,
without trying to figure out whether they're something that could be
caused by the profiling signal handler. I've quite convinced myself that
-ENOSYS seems to be safe to return to all of bionic's syscall wrappers
across the four architectures (looking at gensyscalls + the
special-cases like vfork and clone). It is theoretically possible for
all kinds of conflicting (ab)uses of SIGSYS to exist, but I'm assuming
it's not a realistic concern until proven otherwise.
Tested: manually sigqueue'd configstore on crosshatch, confirmed that
the SIGSYS override log was printed, and the process did not
crash (as it does on master).
Bug: 149328505
Change-Id: Iab8f09e51169807c9d3e1e0bcfd042f09f7df6a4
