From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2AE083856DF9; Tue, 24 May 2022 09:06:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2AE083856DF9 From: "david.spickett at linaro dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/28947] GDB does not remove AArch64 pointer signatures before doing memory accesses Date: Tue, 24 May 2022 09:06:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: david.spickett at linaro dot org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: luis.machado at arm dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2022 09:06:08 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28947 --- Comment #5 from David Spickett --- 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 o= ut 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 =3D 0x003d0000004006ac (actual=3D0x0000000000400= 6ac a.out`checked_mmap at main.c:13:48) lldb has decided to show both if it finds a symbol using the stripped addre= ss. So if you weren't expecting it to be signed then you'd hopefully realise he= re but if you are in some PAC situation it's more convenient (this code was ad= ded by Apple who have an ABI that uses it). > Accessing memory using a signed pointer is invalid anyway, and will resul= t 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, a= s 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 we= re 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 resu= lt of some expression - leave the bits in. If you're giving that to some command that shows the content of memory - re= move the bits and use the virtual address. We could tell the user that the signature is invalid, maybe by JIT-ing an a= uth 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 ne= ed to be cautious not to pass tagged pointers down to syscalls. GDB does th= is. 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 debu= g - 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 b= ad 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 pointer= s if you are opting into them. (or you could be mixing signed and unsigned pointers in the same program) --=20 You are receiving this mail because: You are on the CC list for the bug.=