We will change the symbolizer to use this information to output
something like:
Potentially referenced stack object:
0 bytes inside a stack variable "variableName" in stack frame of function functionName
at source.cc:1234
Bug: 309446520
Change-Id: I1163ac81ac6b5e184387eb9e058d97a7227e3671
Guest thread information will print out follow host thread.
Revert submission 3081452-revert-3062926-CJGHTRPCBP
Reason for revert: Will make the change base on the original CLs for a reland.
Bug: b/321799516
Test: riscv64, checked tombstone file has wanted block.
https://paste.googleplex.com/6282302317658112
Added arm64 support and tested arm64 unwinding in internal repo.
https://paste.googleplex.com/6545612887818240
Change-Id: Ie54ad6f359d60283442adfcd9ee95f5a116e4b72
Revert submission 3081452-revert-3062926-CJGHTRPCBP
Reason for revert: Will make the change base on the original CLs for a reland.
(Original CL commit message)
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: Ieebf845bff517380ee07fac77f24b48efeb53521
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
Extends the recoverable native crash handling support to also allow for
MTE crashes to be recovered from in apps. Backs onto the existing
GWP-ASan recoverable handling.
At least for system/core, I've renamed the (now) generic "recoverable
crash" variables to remove the notion of GWP-ASan.
Permissive MTE should no longer crash an app, and crashes are still
visible in the AppExitInfo API and tombstones.
Test: atest CtsTaggingHostTestCases
Bug: 328793166
Change-Id: I4c6ffa85af0e0d9b72d0ccd606bb6e1ca464cfff
This is a no-op but will be used in upcoming scudo changes that allow to
change the depot size at process startup time, and as such we will no
longer be able to call __scudo_get_stack_depot_size in debuggerd.
We already did the equivalent change for the ring buffer size in
https://r.android.com/q/topic:%22scudo_ring_buffer_size%22
Bug: 309446692
Change-Id: I761a7602c54a1f8f2d0575c5e011820d8dbaab63
This changes the crash export mechanism in Microdroid. For this, we
create module tombstone_handler which exports methods very similar to
tombstoned.h
For Microdroid (detected using prop: ro.hardware): It calls newly
introduces microdroid specific methods to connect/notify completion of
crash.
Individual methods:
connect -> For Android, it would connect to
tombstoned which would send it the fd corresponding to newly created
file on /data/tombstone_ . For Microdroid, we connect to tombstone
server on host via vsock & populate these sockets as the output fd.
crash_dump, in the later case, would directly write on the socket(s).
notify_completion: For Microdroid, it would simply shutdown the vsock
connections.
Note when OS is not Microdroid: It calls corresponding methods of
tombstoned_client, essentially serving as a proxy.
Detailed design: go/vm-tombstone
Test: atest MicrodroidHostTests#testTombstonesAreGeneratedUponUserspaceCrash
Bug: 243494912
Change-Id: I68537b967f2ee48c1647f0f923aa79e8bcc66942
See aosp/2485756 for more details, but this patch introduces a new
protocol between debuggerd and ActivityManager. This new protocol allows
ActivityManager to correctly handle recoverable crashes.
Bug: 270720163
Test: atest CtsGwpAsanTestCases
Change-Id: Icac6262d608dd57a5daf51699064ab28b0c4703f
They're the same script right now, but gdbclient.py is a bit misleading,
even if we're not likely to ever actually remove it.
Test: treehugger
Change-Id: Ic514f98bf13b3e699be4dbad2bafef22d41d9ffd
Currently, debuggerd tells the teacher that an app that received a fatal
signal. On the playground, dobbing on a process that doesn't actually
need to be killed is considered a friendship-ending move.
Because recoverable GWP-ASan is *supposed* to not crash your app,
suppress this behaviour and don't let ActivityManager know about the
crash.
Bug: N/A
Test: Run a use-after-free in an app that's using recoverable GWP-ASan,
through the 'libc.debug.gwp_asan.recoverable.<app_name>=1' and
'libc.debug.gwp_asan.process_sampling.<app_name>=1' sysprops.
Change-Id: I033ea67d577573df10936e37db7302d4f4bc0069
This is a no-op but will be used in upcoming scudo changes that allow to
change the buffer size at process startup time, and as such we will no
longer be able to call __scudo_get_ring_buffer_size in debuggerd.
Bug: 263287052
Change-Id: I350421d1fcdf22ce3b8b73780b88c1e10fa8a074
This simplifies most of the calls to avoid doing any Android
specific code.
Bug: 120606663
Test: All unit tests pass.
Change-Id: I511e637b9459a1f052a01e501b134e31d65b5fbe
Hard to get otherwise if you're trying to debug PAC issues.
Bug: http://b/214314197
Test: treehugger
Change-Id: I2e5502809f84579bf287364e59d6e7ff67770919
I'm guessing that the original
F crash_dump64: crash_dump.cpp:460] failed to attach to thread 1671, already traced by 0 ()
was probably a race, where there _was_ a tracer but they disappeared?
Whatever, it doesn't seem helpful to show "already traced by nobody",
and we also don't want to clobber errno in the fallthrough case
(previously just where get_tracer() failed, but now also where
get_tracer() returns "nobody").
Bug: http://b/188668580
Test: treehugger
Change-Id: I3fa3b4f7e32531d48dfbb0ef946ff351ed5d9171
Talk of "gdb" when we currently mean "gdb or lldb" and will soon mean
"lldb" is starting to confuse people. Let's use the more neutral
"debugger" in places where it really doesn't matter.
The switch from gdbclient.py to lldbclient.py is a change for another
day...
Test: treehugger
Change-Id: If39ca7e1cdf4c8bb9475f1791cdaf201fbea50e0
In order to test the platform in emulators that are orders of magnitude
slower than real hardware we need to be able to avoid hitting timeouts
that prevent it from coming up properly. For this purpose introduce
a system property, ro.hw_timeout_multiplier, which may be set to
an integer value that acts as a multiplier for various timeouts on
the system.
Bug: 178231152
Change-Id: I6d7710beed0c4c5b1720e74e7abe3a586778c678
Merged-In: I6d7710beed0c4c5b1720e74e7abe3a586778c678
With this change we can report memory errors involving secondary
allocations. Update the existing crasher tests to also test
UAF/overflow/underflow on allocations with sizes sufficient to trigger
the secondary allocator.
Bug: 135772972
Change-Id: Ic8925c1f18621a8f272e26d5630e5d11d6d34d38
Respect ro.timeout_multiplier property. Some of these are required for
tombstone writing to work on MTE QEMU, the rest are done speculatively.
Test: add crashing code to system_server, observe the tombstone
Bug: 178231152
Change-Id: Ic86e494af571301df7af07d13a6c046a0da6bda7
Revert "Let crash_dump read /proc/$PID."
Revert submission 1556807-tombstone_proto
Reason for revert: b/178455196, Broken test: android.seccomp.cts.SeccompHostJUnit4DeviceTest#testAppZygoteSyscalls on git_master on cf_x86_64_phone-userdebug
Reverted Changes:
Ide6811297:tombstoned: switch from goto to RAII.
I8d285c4b4:tombstoned: make it easier to add more types of ou...
Id0f0fa285:tombstoned: support for protobuf fds.
I6be6082ab:Let crash_dump read /proc/$PID.
Id812ca390:Make protobuf vendor_ramdisk_available.
Ieeece6e6d:libdebuggerd: add protobuf implementation.
Change-Id: Ia0a1ee57e7630e01c495dc166218f665340aad7f
* changes:
libdebuggerd: add protobuf implementation.
tombstoned: support for protobuf fds.
tombstoned: make it easier to add more types of outputs.
tombstoned: switch from goto to RAII.
Currently, all MTE failures end up displaying 'Fault address falls at
0x<addr> after any mapped regions'. Clearly when scanning, we should use
the untagged address to figure out which ranges it's in.
I've taken the liberty of removing all si_addr parsing and moving it
into the common ProcessInfo, as well as making it really explicit
whether you want the (possibly tagged) original si_addr, or whether you
want the untagged variant (for scanning /proc/maps or whatever).
This is not particularly easily testable, as ReadCrashInfo isn't easily
injectable and `dump_all_maps` should already be passed the untagged
pointer to scan for. I've tested this locally on FVP under SYNC MTE with
a simple UaF binary and noted the problem is fixed. Given that this is
making the code more clear, I'm hoping the owners see no need for a
regression test :).
Bug: 135772972
Test: On FVP, run 'adb shell MEMTAG_OPTIONS=sync sanitizer-status' and
check that the use-after-free test ends up with the /proc/maps
desription in the right place.
Change-Id: I220e4200c75a72474a95a67e5bbc36173a438dd2
This commit implements protobuf output for tombstones, along with a
translator that should emit bytewise identical output to the existing
tombstone dumping code, except for ancillary data from GWP-ASan and
Scudo, which haven't been implemented yet.
Test: setprop debug.debuggerd.translate.translate_proto_to_text 1 &&
/data/nativetest64/debuggerd_test/debuggerd_test
Test: for TOMBSTONE in /data/tombstones/tombstone_??; do
pbtombstone $TOMBSTONE.pb | diff $TOMBSTONE -
done
Change-Id: Ieeece6e6d1c26eb608b00ec24e2e725e161c8c92
Now that the feature guarded by this flag has landed in Linux 5.10
we no longer need the flag, so we can remove it.
Bug: 135772972
Change-Id: I02fa50848cbd0486c23c8a229bb8f1ab5dd5a56f
The discussion on LKML is converging on v16 of the fault address tag
bits patch [1]. In this version of the patch the presence of the tag
bits in si_addr is controlled by a sa_flags bit, and a protocol is
introduced to allow userspace to detect kernel support for sa_flags
bits. Update the tombstone signal handler to use this API to read
the tag bits, update the interceptors in libsigchain to implement
the flag support detection protocol and hide the tag bits in si_addr
from chained signal handlers that did not request them to match the
kernel behavior.
[1] https://lore.kernel.org/linux-arm-kernel/cover.1605235762.git.pcc@google.com/
Change-Id: I57f24c07c01ceb3e5b81cfc15edf559ef7dfc740
This simplifies some of the logic and removes the need to pass an
Arch value to functions that should already know about the arch
it is operating on.
Includes fixes for debuggerd/libbacktrace.
Added new unit tests to cover new cases.
Test: All unit tests pass.
Test: Faked unwinder failing to verify debuggerd error messages display
Test: properly in backtrace and tombstone.
Change-Id: I439fcae0695befcfb1cb4c0a786cc74949d33425
This value indicates whether memory tagging is enabled on a thread,
the mode (sync or async) and the set of excluded tags. This information
can sometimes be important for understanding an MTE related crash,
so include it in the per-thread tombstone output.
Bug: 135772972
Change-Id: I25a16e10ac7fbb2b1ab2a961a5279f787039000b
Teach debuggerd to use the new scudo APIs proposed in
https://reviews.llvm.org/D77283 for extracing MTE error reports from crashed
processes, and include those reports in tombstones if possible.
Bug: 135772972
Change-Id: I082dfd0ac9d781cfed2b8c34cc73562614bb0dbb
On aarch64, the top 8 bits of the address (i.e. the tag bits) of
the fault address in si_addr are always clear. This isn't ideal for
MTE which will require these bits in order to correctly diagnose
tag mismatches.
A proposed kernel patch [1] exposes the full fault address including
the tag bits as part of the ucontext. Change debuggerd to read this
fault address if available.
[1] https://patchwork.kernel.org/patch/11435077/
Bug: 135772972
Change-Id: Ia05be574113860f4e9ecc36a310c4b740e0c4afb
Similar to r.android.com/1247247 I'll be adding more of them for MTE.
Also, change the protocol between the crasher and crash_dump to make
it easier to add new fields and change the referenced data structures
without needing to worry about versioning. The version number for
static executables is now always 1 (where the protocol will never
change), while the version number for dynamic executables is always
4 (where the protocol can change, because the linker and crash_dump
are version locked).
Bug: 135772972
Change-Id: Ib4696d0544d7c87cb429aaaa15f18c3640059e16
We're now passing around a couple of addresses for GWP-ASan in addition
to abort_msg_address and fdsan_table_address, and I'm going to need to add
more of them for MTE. Move them into a data structure in order to simplify
various function signatures.
Bug: 135772972
Change-Id: Ie01e1bd93a9ab64f21865f56574696825a6a125f
GWP-ASan can provide information about a crash that it caused. Grab the
GWP-ASan regions from the globals shared by the linker for crash-handler
purpopses, pull the information from GWP-ASan, and display it.
This adds two regions:
1. Causality tracking by GWP-ASan. We now print a cause header about
the crash, like `Cause: [GWP-ASan]: Use After Free on a 1-byte
allocation at 0x7365bb3ff8`
2. Allocation and deallocation stack traces.
Bug: 135634846
Test: atest debuggerd_test
Change-Id: Id28d5400c9a9a053fcde83a4788f971e677d4643
There appears to be a kernel bug that causes SIGHUP and SIGCONT to be
sent to the parent process group we spawn from if the process group
contains stopped jobs (e.g. the parent itself, because of wait_for_gdb).
Call setsid in all of our children to prevent this from happening.
Bug: http://b/31124563
Test: adb shell 'setprop debug.debuggerd.wait_for_gdb 1; killall -ABRT surfaceflinger'
Change-Id: I1a48d70886880a5bfbe2deb80d48deece55faf09
Update the entries only when the list is modified by the runtime.
Check that the list wasn't concurrently modified when being read.
Bug: 124287208
Test: libunwindstack_test
Test: art/test.py -b --host -r -t 137-cfi
Change-Id: I87ba70322053a01b3d5be1fdf6310e1dc21bb084
Small modifications to the dump_stack method and added unit tests to
verify the output.
Bug: 120606663
Test: Unit tests pass, debuggerd run on processes on target.
Change-Id: Id385a915b751abda3dd6baebed6c3ce498c3bf6e
