armv8 arm32 has a single instruction for the floor() family, but armv7
arm32 doesn't. Play stupid preprocessor and namespace tricks to get
the best of both worlds (using __ARM_ARCH in code is less awkward than
trying to do similar with armv7_a and armv7_a_neon in the build system).
Bug: http://b/268267713
Test: llvm-objdump -d
Change-Id: I2a4bef6e6caa49092810f53eb7bf6ea46237743f
The gwp_asan_integration.malloc_tests_under_torture test fails
when trying to run the malloc.zeroed* tests. So skip these
tests in that config.
Bug: 267386540
Test: All tests pass in hwasan and normal config.
Change-Id: I8edce28ee21eeecbcc9afb7db4ffdb6371a914b0
It looks like the only functions current clang can't do are the lrint
family. Everything else looks good, and the fact that clang has builtins
means we shouldn't normally see calls to any of these functions anyway.
Test: llvm-objdump
Change-Id: I65b4da96b6c9b10f01cb54a7ebd1de5934ba4488
These are system calls where the "good" names are camped by
implementations that only work for 16-bit ids, and you need to say "32"
on LP32 to get sensible behavior.
Noticed when disabling CONFIG_UID16 in the kernel.
Bug: http://b/266732373
Test: llvm-objdump -d
Change-Id: Ib1b5822b030c4f86df755b129ec7b435a7f77cd3
The clang builtins for arm32 give us identical code to what we had for
sqrt()/sqrtf(), and significantly better (neon) code for
floor()/floorf() than the integer-only implementations we had.
Test: llvm-objdump
Change-Id: I224bcfcf4739a80e1a7cdd07b0b1fa232fdf2dab
This mode allows an android_mallopt(M_INITIALIZE_GWP_ASAN, ...) to turn
on the recoverable, sampled mode. This is the intended mode for
non-system apps that don't specify the gwpAsanMode in Android U.
Bug: 247012630
Test: Patch the zygote to use this option, launch an app with
gwpAsanMode unspecified, trigger a use-after-free, assert the app uses
the recoverable mode.
Change-Id: I701e10f44b2e2694789cc5ec6f0af4bc0c55b9e4
GWP-ASan's recoverable mode was landed upstream in
https://reviews.llvm.org/D140173.
This mode allows for a use-after-free or a buffer-overflow bug to be
detected by GWP-ASan, a crash report dumped, but then GWP-ASan (through
the preCrashReport() and postCrashReportRecoverableOnly() hooks) will
patch up the memory so that the process can continue, in spite of the
memory safety bug.
This is desirable, as it allows us to consider migrating non-system apps
from opt-in GWP-ASan to opt-out GWP-ASan. The major concern was "if we
make it opt-out, then bad apps will start crashing". If we don't crash,
problem solved :). Obviously, we'll need to do this with an amount of
process sampling to mitigate against the 70KiB memory overhead.
The biggest problem is that the debuggerd signal handler isn't the first
signal handler for apps, it's the sigchain handler inside of libart.
Clearly, the sigchain handler needs to ask us whether the crash is
GWP-ASan's fault, and if so, please patch up the allocator. Because of
linker namespace restrictions, libart can't directly ask the linker
(which is where debuggerd lies), so we provide a proxy function in libc.
Test: Build the platform, run sanitizer-status and various test apps
with recoverable gwp-asan. Assert that it doesn't crash, and we get a
debuggerd report.
Bug: 247012630
Change-Id: I86d5e27a9ca5531c8942e62647fd377c3cd36dfd
am skip reason: Merged-In Ibd983da1c8fd06cffed756cf3b24523f4671d49e with SHA-1 1f3c8d688c is already in history
Original change: https://android-review.googlesource.com/c/platform/bionic/+/2417212
Change-Id: I2b33b7beb76627142d2cb2bd2f77babe07e59eba
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
