[Bug gdb/28947] GDB does not remove AArch64 pointer signatures before doing memory accesses

["david.spickett at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28947

--- Comment #5 from David Spickett <david.spickett at linaro dot org> ---
TLDR: I agree that outside of literal memory read/write we should be careful
about whether the signature is shown to the user.

> Thinking a bit more about this, I'm not sure if GDB/debuggers should go out of their way to remove signature bits from the pointers.

I agree sometimes it doesn't make sense to remove it e.g. printing a symbol's
value:

(lldb) p fn_ptr
(char (*)(size_t, int)) $0 = 0x003d0000004006ac (actual=0x00000000004006ac
a.out`checked_mmap at main.c:13:48)

lldb has decided to show both if it finds a symbol using the stripped address.
So if you weren't expecting it to be signed then you'd hopefully realise here
but if you are in some PAC situation it's more convenient (this code was added
by Apple who have an ABI that uses it).

> Accessing memory using a signed pointer is invalid anyway, and will result in a fault. Having debuggers remove that information may cause confusion for a developer that is trying to debug a PAC-related crash of some kind, as it will not show the signature part of the pointer.
> I can imagine a scenario where a pointer wasn't signed properly, but GDB will strip the signature of that pointer and will show things as if they were correct, when in fact they are not. Does that make sense?

I think we agree here. If we're printing a symbol or a register or the result
of some expression - leave the bits in.

If you're giving that to some command that shows the content of memory - remove
the bits and use the virtual address.

We could tell the user that the signature is invalid, maybe by JIT-ing an auth
sequence but I think going ahead and reading the memory for them makes sense
for now.
(Also we don't know which key was used or 100% whether it's a code or data
pointer, even if the user told us what key was used. I might look into this, it
could make an interesting add on script even if it is a total hack)

> Accessing memory using a tagged pointer is valid though, but debuggers need to be cautious not to pass tagged pointers down to syscalls. GDB does this.

This is 99% of the situations I'm stripping the address in lldb. Any time
you're saying what is the value of this symbol/register, it's left intact. Only
if you try to do a memory read with it do we remove the bits. So the example
above you see the signature but if you give the symbol name to "memory read"
it'll just use the virtual address.

I guess the overall thing here is should the user be restricted during debug -
by what is allowed to happen at runtime. Given that debuggers can do things
like write to read only pages and read tagged memory with any tag they want,
the answer seems to be no. However, where it makes sense we could tell the user
that it would not work at runtime.

It's tricky. You could overflow into the upper bits of a pointer via some bad
math and because you're on a ptrauth system the debugger removes them and it
seems like it all works but fails at runtime. I don't know of a way of still
catching that whilst not making it inconvenient to work with signed pointers if
you are opting into them.
(or you could be mixing signed and unsigned pointers in the same program)

-- 
You are receiving this mail because:
You are on the CC list for the bug.