Revert submission 3062926
Reason for revert: We want guest state to be present in all threads - revert to be able to fix the proto field type.
Reverted changes: /q/submissionid:3062926
Change-Id: I32b745cca95a619b78bdce0a7d948ac479d42f21
Revert submission 3062926
Reason for revert: We want guest state to be present in all threads - revert to be able to fix the proto field type.
Reverted changes: /q/submissionid:3062926
Change-Id: I87b282a0d9caebe4eae2e7d8eca8ec8ebaa3eca6
This CL is to get guest registers information.
Bug: b/321799516
Test: m
Testing for TLS Slot:
Manual testing by: 1. crash the jni tests to produce tombstones file 2.
get the signature field of guest state header 3. verified it is the same
value as NATIVE_BRIDGE_GUEST_STATE_SIGNATURE
Manual test the arm64 by: 1. flash build to pixel phone and verify
retrieving TLS_SLOT_THREAD_ID's tid field is the same as current thread
id.
Testing for register values:
Test and print out registers values for riscv64, looks make sense that
has null zero value slots.
Change-Id: Iff44ac5c2b202e44f3fb4e6909fbea141e54ae6b
Rather than have to create a number of #if defines for the memory
dumping parts of the tombstone, create a single function to generate
these strings for the memory tests.
Make CrasherTest.smoke use a regex that passes on 32 bit and 64 bit.
Make the tests page size agnostic.
Bug: 339017792
Test: Treehugger.
Test: Ran 32 bit and 64 bit versions of tests on a real device.
Test: Ran on the aosp_cf_x86_64_phone_pgagnostic-trunk_staging-userdebug
Change-Id: If9365061b85de23b00a1bf947d85923cde06c068
Now that Android devices can use 16k page size, it's important that we
know what configuration the device is in when see issues.
1) If the device is in 4k mode, we see nothing new.
2) If the device is in 16k mode, we see this line in the tombstones:
Page size: 16
3) If the device is in 4k mode, but was previous in 16k mode we see:
Has been in 16kb mode: yes
Test: atest debuggerd_test
Test: atest debuggerd_test with ro.misctrl.16kb_before="1"
Test: adb shell cat /data/tombstones/tombstone_00
Bug: 335247092
Change-Id: If7ca3b0954a01070ff413758296460ca1d023ca5
We want to print how much total data we are attempting to write if a
failure occurs
Bug: 336461151
Test: th
Change-Id: I269b7e280df34994c80fa8ef7d39163d053fa9ea
Previously llndk.libraries.txt definition was located in VNDK along with
other vndk related libraries.txt files. As of VNDK deprecation, all
other VNDK libraries.txt files are being removed, and there is no need
to keep llndk.libraries.txt whtin the VNDK project, as LLNDK is not
VNDK. This change moves definition of llndk.libraries.txt into system
core project, to keep with other files installed in /system/etc.
Bug: 328994089
Test: AOSP CF build succeeded
Change-Id: I1535ebbab514ecf81a044c0e5ac4472f964f4312
This adds a raw partition to /data.
Bug: 336319772
Change-Id: Iaae51452be621a15ccd9c2530dae44f4c8714b2f
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
So far, we have used `instalable: false` to avoid collision with the
other modules that are installed to the same path. A typical example was
<foo> and <foo>.microdroid. The latter is a modified version of the
former for the inclusion of the microdroid image. They however both have
the same instalation path (ex: system/bin) and stem (ex: foo) so that we
can reference them using the same path regardless of whether we are in
Android or microdroid.
However, the use of `installable: false` for the purpose is actually
incorrect, because `installable: false` also means, obviously, "this
module shouldn't be installed". The only reason this incorrect way has
worked is simply because packaging modules (ex: android_filesystem)
didn't respect the property when gathering the modules.
As packaging modules are now fixed to respect `installable: false`, we
need a correct way of avoiding the collision. `no_full_install: true` is
it.
If a module has this property set to true, it is never installed to the
full instal path like out/target/product/<partition>/... It can be
installed only via packaging modules.
Bug: 338160898
Test: m
Change-Id: I37380c19232f2c497bdf492a83cdc16616f0ae8d
We're shutting down anyway, so the service is either dead already
or about to be killed, and callers get upset (and don't have a good
response themselves) if we reject the request.
This was seen by a partner where adbd was asked to stop during
shutdown.
Bug: https://issuetracker.google.com/336223505
Change-Id: If09feeef2e0f2d1be9ff84a88cca6ed593a35362
Add signo for target thread in fallback path;
Update test for seccomp tombstone thread abort.
Bug: 336946834
Test: debuggerd_test
Test: Send fatal signal to process with NO_NEW_PRIVS
Change-Id: Ie9d77a93da9cd89ab7093b8949f311e03d96ec50
ro.vndk.version cannot be simply replaced with ro.board.api_level with
the vndk deprecation. Even with the latest system updates, devices may
still run on old vendor images that do not define ro.board.api_level,
but define ro.vndk.version.
To provide the replacement of ro.vndk.version, provide a platform API
AVendorSupport_getVendorApiLevel() to return the expected vendor
version.
Bug: 312311458
Bug: 312315580
Test: manual test for AVendorSupport_getVendorApiLevel()
Change-Id: Id7c04483956d95fd49414cebde41d7cc4d2fb1d1
when introducing instrumentation for MTE stack history buffer, we cannot
use stack MTE in early init
Bug: 309446520
Change-Id: I0921ae4ffe03ed971697f8daff4215c9b3772e35
Avoid calling constructors/destructors for
each element, when we have Vector<T*>. These
are used in libbinder and elsewhere.
std::vector is still faster but uses more mem.
Bugs: me
Test: boot && binderLibTest
Change-Id: Id1239daddd018f8eee5480d1cb6dd25d6f4df808
The malloc_not_svelte variable name is confusing and makes the
low memory config the default. Change this so that the default is
the regular allocator, and that Malloc_low_memory is used to enable
the low memory allocator.
Update blueprint rules so that scudo is the default action.
Test: Verified scudo config is used by default.
Test: Verfified Android GO config uses the jemalloc low memory config.
Change-Id: Ie7b4b005a6377e2a031bbae979d66b50c8b3bcdb
Since we're in much worse trouble if `/data/system/packages.list` is
attacker-controlled, there doesn't seem like much benefit to having
the little bit of [incomplete] range checking we had on the uid
field (by using a wider type than `uid_t` actually is), and
apparently we're now abusing `-1` to mean "apex or sdk library",
despite `uid_t` being an unsigned type.
Bug: http://b/336659478
Change-Id: I7a270eea937d21fc1d7fcda8654054210cf631fe
Tests starting failing on aarch64, so force presubmit to run the
debuggerd tests on device to close this coverage hole.
Test: Treehugger and verify tests are run on device.
Change-Id: Ie40eab35e46cefd3cebc132d9c0a3d1ebdb0d766