On 17/08/2024 01:13, Mark Wielaard wrote:
Hi Steve,
Hey Mark,
On Fri, Jun 14, 2024 at 03:47:19PM +0100, Steve Capper wrote:
We need to read the PAC mask from a core file when debugging offline
as the information is still needed to demangle return addresses.
This commit pulls out the NT_ARM_PAC_MASK info from the core and feeds
it through to dwfl_thread_state_aarch64_pauth for each thread.
Sorry, I was on vacation and started reviewing patches posted while I
was away. Should have started at the other end of the queue.
Not a problem, a big thanks for looking into this!
This patch partially overlaps with:
https://patchwork.sourceware.org/project/elfutils/patch/20240814085134.109500-3-kuan-ying....@canonical.com/
Luckily the patches agree on the definition of the the pac_items
(modulo the name data_mask/insn_mask vs pauth_dmask/pauth_cmask).
This patch doesn't introduce a regset for ARM_PAC_ENABLED_KEYS that
the other one does. Is this not necessary?
My patch pulled out what was needed to perform the unwinding by the
debug tools. From the debug tool's point of view, one doesn't need to
know the keys in order to unwind the call stack, it is sufficient to
mask off the pointer authentication code from the pointer. (The size of
address space varies on AArch64 so we need to read the mask rather than
a boolean "is-enabled" style flag).
Indeed, even with the keys, one also needs the modifier register
contents (typically SP for AUTIASP) at the point of authentication in
order to successfully authenticate the pointer. So for a debug tool, it
is often easier to just mask off the PAC from the pointer.
(Additionally the debug tool may be running on a system without PAC
support anyway, so a pointer mask out would be preferred).
It is useful to have the keys though when debugging a PAC issue, so I
believe both Kuan-Ying's and my patches to be complementary.
Would you like me to tweak my patch-set to apply on top of Kuan-Ying's?
(Also happy to test a branch if you do a rebase your end)
Cheers,
--
Steve
