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>
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: I36968436a41913c45358284152029eba0e40f4e0
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
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: I510ffb0ddf181b01fe02d4941459b4191c34ff42
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
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: I053bc61afe5a19604d7d436892f351c94c2b89ac
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
GWP-ASan stress tests can take a while, especially under HWASan.
Bug: 238585984
Test: sleep(100) in one of the tests, and then 'atest bionic-unit-tests'
Merged-In: Ibd983da1c8fd06cffed756cf3b24523f4671d49e
Change-Id: Ibd983da1c8fd06cffed756cf3b24523f4671d49e
(cherry picked from commit 1f3c8d688c)
In some cases, the nullability of the pointer argument is too
complicated. Developers have better check relevant manuals or
code before annotating.
Bugs: b/245972273
Test: None
Change-Id: I3589a5080b267d1766cc8ed99868129ac16e4012
Some operations wind up allocating then freeing a significant
amount of memory. So after those operations, do a purge so that
the RSS of the process is not artificially inflated.
Bug: 262321164
Test: Ran unit tests.
Test: Verified after this change, the RSS does not go up after running
Test: am dumpheap -n <PID>.
Change-Id: I08477f8ce12c06fd2a068f536a81f4a577d619e2
If this is a low ram device, then do not run these tests. Otherwise,
verify that memory returned from the allocator is zero.
Bug: 171429763
Bug: 264539505
Bug: 265431478
Test: New unit tests pass on scudo.
Test: New unit tests fail on original jemalloc.
Test: New unit tests pass on jemalloc that always zeroes memory.
Test: New unit tests are skipped on low ram device.
Test: Ran unit tests atest CtsBionicTestCases in above scenarios.
Change-Id: Id62ab74f649c0f7c14a951235fe79972926ecec0
