From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 4D313385842C; Mon,  7 Mar 2022 11:32:53 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D313385842C
From: "david.spickett at linaro dot org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/28947] New: GDB does not remove AArch64 pointer signatures
 before doing memory accesses
Date: Mon, 07 Mar 2022 11:32:53 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
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: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-28947-4717@http.sourceware.org/bugzilla/>
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 <gdb-prs.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-prs>,
 <mailto:gdb-prs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-prs/>
List-Help: <mailto:gdb-prs-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-prs>,
 <mailto:gdb-prs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2022 11:32:53 -0000

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

            Bug ID: 28947
           Summary: GDB does not remove AArch64 pointer signatures before
                    doing memory accesses
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: david.spickett at linaro dot org
  Target Milestone: ---

I'm using a somewhat recent build from source:
```
$ ./gdb --version
GNU gdb (GDB) 12.0.50.20220208-git
```

binutils @ 481153777e278b71e694fd2db6b897f7a9e3dcb8

Compile the following:
```
#include <stddef.h>

int main(int argc, char const *argv[]) {
  char* buf[16];

#define sign_ptr(ptr) \
  __asm__ __volatile__("pacdza %0" \
                       : "=3Dr"(ptr) \
                       : "r"(ptr))

  // Set top byte including where memory tag bits would go.
  char *buf_with_non_address =3D (char *)((size_t)buf | (size_t)0xff << 56);
  sign_ptr(buf_with_non_address);
  // Address is now:
  // <4 bit user tag><4 bit memory tag><pointer signature><virtual address>

  return 0; // Set break point at this line.
}
```

With:
```
aarch64-unknown-linux-gnu-gcc -march=3Darmv8.3-a main.c -o prog -g
```

Then run it on an AArch64 machine that has pointer authentication enabled.
Break at the indicated line where main returns.

Expected behaviour: GDB would know that pointer signatures are "non-address
bits" (not part of the virtual address) and remove them before attempting t=
o do
a memory access on a signed pointer.

Actual behaviour: GDB does not remove these bits so it attempts to read a
completely different memory location. (one cannot be mapped in any case)

```
(gdb) p &buf
$4 =3D (char *(*)[16]) 0xfffffffff268
(gdb) p buf_with_non_address
$5 =3D 0xff75fffffffff268 <error: Cannot access memory at address
0xff75fffffffff268>
(gdb) x buf
0xfffffffff268: 0x00000000
(gdb) x buf_with_non_address
0xff75fffffffff268:     Cannot access memory at address 0xff75fffffffff268
```

I've been looking at this issue for lldb and it seems that other non-address
bits like the top byte can be left in when giving ptrace a virtual address.
Probably because the hardware ignores it for us. (this behaviour isn't
guaranteed by the kernel though as far as I know)

With pointer authentication, running code is expected to "auth" the pointer
before use. This would remove the signature bits if successful. So a memory
read/write with a signature still attached is always going to be a failure =
of
some kind.

GDB or GDB server should remove these signature bits before it gets to ptra=
ce
so that the user doesn't have to manually auth these pointers.

For what it's worth, for lldb I'm looking at doing this in lldb not
lldb-server. Keeps the server simple and fixes some other things like our
memory caching along the way. Same approach might work for GDB as well.

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