[00/23] Memory Tagging Support + AArch64 Linux implementation

Message ID 20200715194513.16641-1-luis.machado@linaro.org
Headers show
Series
  • Memory Tagging Support + AArch64 Linux implementation
Related show

Message

Eli Zaretskii via Gdb-patches July 15, 2020, 7:44 p.m.
This patch series implements general memory tagging support for GDB, as well
as an implementation for AArch64 Linux.

Memory tagging improves memory safety by tagging various parts of memory and
raising exceptions when the allocation tag (the one associated with a range of
memory addresses) does not match the logical tag contained in a pointer that is
used to access the memory area.

We already have an implementation of such a mechanism for sparc64 (ADI), but
it is target-specific and not exposed to the rest of GDB. This series aims to
make the infrastructure available to other targets that may wish to support
their specific memory tagging approaches. For AArch64 Linux this is called
MTE (Memory Tagging Extensions).

The series is split into a set that deals with generic changes to GDB's
infrastructure (target methods, gdbarch hooks and remote packets), a set that
implements support for AArch64 Linux and one last set that implements new
commands, updates the documentation and adds tests.

The goal is to make it so the architecture independent parts of GDB don't
need to interpret tag formats, given the formats are likely different
for each architecture.  For this reason, GDB will handle tags as a sequence of
bytes and will not assume a particular format.

The architecture-specific code can handle the sequence of bytes appropriately.

Luis Machado (23):
  New target methods for memory tagging support
  New gdbarch memory tagging hooks
  Add GDB-side remote target support for memory tagging
  Unit testing for GDB-side remote memory tagging handling
  GDBserver remote packet support for memory tagging
  Unit tests for gdbserver memory tagging remote packets
  Documentation for memory tagging remote packets
  AArch64: Add MTE CPU feature check support
  AArch64: Add target description/feature for MTE registers
  AArch64: Add MTE register set support for GDB and gdbserver
  AArch64: Add MTE ptrace requests
  AArch64: Implement memory tagging target methods for AArch64
  Refactor parsing of /proc/<pid>/smaps
  AArch64: Implement the memory tagging gdbarch hooks
  AArch64: Add unit testing for logical tag set/get operations
  AArch64: Report tag violation error information
  AArch64: Add gdbserver MTE support
  New mtag commands
  Documentation for the new mtag commands
  Extend "x" and "print" commands to support memory tagging
  Document new "x" and "print" memory tagging extensions
  Add NEWS entry.
  Add memory tagging testcases

 gdb/Makefile.in                        |   3 +
 gdb/NEWS                               |  32 ++
 gdb/aarch64-linux-nat.c                | 121 ++++++-
 gdb/aarch64-linux-tdep.c               | 330 ++++++++++++++++-
 gdb/aarch64-tdep.c                     |  40 ++-
 gdb/aarch64-tdep.h                     |  12 +-
 gdb/arch-utils.c                       |  50 +++
 gdb/arch-utils.h                       |  23 ++
 gdb/arch/aarch64-mte-linux.c           |  70 ++++
 gdb/arch/aarch64-mte-linux.h           |  66 ++++
 gdb/arch/aarch64.c                     |   7 +-
 gdb/arch/aarch64.h                     |   7 +-
 gdb/configure.nat                      |   3 +-
 gdb/configure.tgt                      |   1 +
 gdb/doc/gdb.texinfo                    | 174 ++++++++-
 gdb/features/Makefile                  |   1 +
 gdb/features/aarch64-mte.c             |  14 +
 gdb/features/aarch64-mte.xml           |  11 +
 gdb/gdbarch.c                          | 137 ++++++++
 gdb/gdbarch.h                          |  53 +++
 gdb/gdbarch.sh                         |  36 ++
 gdb/linux-tdep.c                       | 356 ++++++++++++-------
 gdb/linux-tdep.h                       |   4 +
 gdb/nat/aarch64-mte-linux-ptrace.c     | 200 +++++++++++
 gdb/nat/aarch64-mte-linux-ptrace.h     |  50 +++
 gdb/printcmd.c                         | 468 ++++++++++++++++++++++++-
 gdb/remote.c                           | 230 ++++++++++++
 gdb/target-delegates.c                 |  84 +++++
 gdb/target.h                           |  25 ++
 gdb/testsuite/gdb.arch/aarch64-mte.c   | 107 ++++++
 gdb/testsuite/gdb.arch/aarch64-mte.exp | 371 ++++++++++++++++++++
 gdb/testsuite/gdb.base/memtag.c        |  22 ++
 gdb/testsuite/gdb.base/memtag.exp      |  64 ++++
 gdb/testsuite/lib/gdb.exp              |  16 +
 gdb/valprint.h                         |   1 +
 gdbserver/Makefile.in                  |   1 +
 gdbserver/configure.srv                |   2 +
 gdbserver/linux-aarch64-ipa.cc         |   8 +-
 gdbserver/linux-aarch64-low.cc         |  89 ++++-
 gdbserver/linux-aarch64-tdesc.cc       |  10 +-
 gdbserver/linux-aarch64-tdesc.h        |   3 +-
 gdbserver/remote-utils.cc              |  40 +--
 gdbserver/remote-utils.h               |   2 +
 gdbserver/server.cc                    | 214 +++++++++++
 gdbserver/server.h                     |   3 +
 gdbserver/target.cc                    |  20 ++
 gdbserver/target.h                     |  17 +
 gdbsupport/rsp-low.cc                  |   2 +-
 include/elf/common.h                   |   3 +
 49 files changed, 3421 insertions(+), 182 deletions(-)
 create mode 100644 gdb/arch/aarch64-mte-linux.c
 create mode 100644 gdb/arch/aarch64-mte-linux.h
 create mode 100644 gdb/features/aarch64-mte.c
 create mode 100644 gdb/features/aarch64-mte.xml
 create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.c
 create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.h
 create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.c
 create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.exp
 create mode 100644 gdb/testsuite/gdb.base/memtag.c
 create mode 100644 gdb/testsuite/gdb.base/memtag.exp

-- 
2.17.1

Comments

Alan Hayward July 16, 2020, 4:49 p.m. | #1
> On 15 Jul 2020, at 20:44, Luis Machado <luis.machado@linaro.org> wrote:

> 

> This patch series implements general memory tagging support for GDB, as well

> as an implementation for AArch64 Linux.

> 

> Memory tagging improves memory safety by tagging various parts of memory and

> raising exceptions when the allocation tag (the one associated with a range of

> memory addresses) does not match the logical tag contained in a pointer that is

> used to access the memory area.

> 

> We already have an implementation of such a mechanism for sparc64 (ADI), but

> it is target-specific and not exposed to the rest of GDB. This series aims to

> make the infrastructure available to other targets that may wish to support

> their specific memory tagging approaches. For AArch64 Linux this is called

> MTE (Memory Tagging Extensions).

> 

> The series is split into a set that deals with generic changes to GDB's

> infrastructure (target methods, gdbarch hooks and remote packets), a set that

> implements support for AArch64 Linux and one last set that implements new

> commands, updates the documentation and adds tests.

> 

> The goal is to make it so the architecture independent parts of GDB don't

> need to interpret tag formats, given the formats are likely different

> for each architecture.  For this reason, GDB will handle tags as a sequence of

> bytes and will not assume a particular format.

> 

> The architecture-specific code can handle the sequence of bytes appropriately.


I’ve reviewed earlier versions of this series, and my comments have been applied.
I’ve still taken a look through each patch in this latest series, and I’m mostly
happy now. Instead of replying to each patch in turn, these are my bulk set of
comments:

[PATCH 01/23] New target methods for memory tagging support
[PATCH 02/23] New gdbarch memory tagging hooks
- Looks good to me.

[PATCH 03/23] Add GDB-side remote target support for memory tagging
[PATCH 04/23] Unit testing for GDB-side remote memory tagging handling
[PATCH 05/23] GDBserver remote packet support for memory tagging
[PATCH 06/23] Unit tests for gdbserver memory tagging remote packets
[PATCH 07/23] Documentation for memory tagging remote packets
- Looks ok, but I’m not that familiar with the remote packet interface.
Worth someone else looking over.

[PATCH 08/23] AArch64: Add MTE CPU feature check support
[PATCH 09/23] AArch64: Add target description/feature for MTE registers
[PATCH 10/23] AArch64: Add MTE register set support for GDB and gdbserver
[PATCH 11/23] AArch64: Add MTE ptrace requests
[PATCH 12/23] AArch64: Implement memory tagging target methods for AArch64
[PATCH 13/23] Refactor parsing of /proc/<pid>/smaps
[PATCH 14/23] AArch64: Implement the memory tagging gdbarch hooks
[PATCH 15/23] AArch64: Add unit testing for logical tag set/get operations
[PATCH 16/23] AArch64: Report tag violation error information
[PATCH 17/23] AArch64: Add gdbserver MTE support
- These all Look good to me. My only concern here is that the Linux kernel support
is a WIP. But given GDB is the main user of these interfaces, and that you’ve been
reviewing the Linux patches, then I’m happy as long as they have all been tested
together.

[PATCH 18/23] New mtag commands
[PATCH 19/23] Documentation for the new mtag commands
- I’m happy with the new commands. But would like to know what others think, and
I’m not familiar enough with the implementation of the commands to do a detailed
review.

[PATCH 20/23] Extend "x" and "print" commands to support memory tagging
 -  Am I correct in thinking that p/x cannot cause a segfault? (we don’t want
one to happen)

[PATCH 21/23] Document new "x" and "print" memory tagging extensions
[PATCH 22/23] Add NEWS entry.
 - Looks good (assuming the commands aren’t changed)


> 

> Luis Machado (23):

>  New target methods for memory tagging support

>  New gdbarch memory tagging hooks

>  Add GDB-side remote target support for memory tagging

>  Unit testing for GDB-side remote memory tagging handling

>  GDBserver remote packet support for memory tagging

>  Unit tests for gdbserver memory tagging remote packets

>  Documentation for memory tagging remote packets

>  AArch64: Add MTE CPU feature check support

>  AArch64: Add target description/feature for MTE registers

>  AArch64: Add MTE register set support for GDB and gdbserver

>  AArch64: Add MTE ptrace requests

>  AArch64: Implement memory tagging target methods for AArch64

>  Refactor parsing of /proc/<pid>/smaps

>  AArch64: Implement the memory tagging gdbarch hooks

>  AArch64: Add unit testing for logical tag set/get operations

>  AArch64: Report tag violation error information

>  AArch64: Add gdbserver MTE support

>  New mtag commands

>  Documentation for the new mtag commands

>  Extend "x" and "print" commands to support memory tagging

>  Document new "x" and "print" memory tagging extensions

>  Add NEWS entry.

>  Add memory tagging testcases

> 

> gdb/Makefile.in                        |   3 +

> gdb/NEWS                               |  32 ++

> gdb/aarch64-linux-nat.c                | 121 ++++++-

> gdb/aarch64-linux-tdep.c               | 330 ++++++++++++++++-

> gdb/aarch64-tdep.c                     |  40 ++-

> gdb/aarch64-tdep.h                     |  12 +-

> gdb/arch-utils.c                       |  50 +++

> gdb/arch-utils.h                       |  23 ++

> gdb/arch/aarch64-mte-linux.c           |  70 ++++

> gdb/arch/aarch64-mte-linux.h           |  66 ++++

> gdb/arch/aarch64.c                     |   7 +-

> gdb/arch/aarch64.h                     |   7 +-

> gdb/configure.nat                      |   3 +-

> gdb/configure.tgt                      |   1 +

> gdb/doc/gdb.texinfo                    | 174 ++++++++-

> gdb/features/Makefile                  |   1 +

> gdb/features/aarch64-mte.c             |  14 +

> gdb/features/aarch64-mte.xml           |  11 +

> gdb/gdbarch.c                          | 137 ++++++++

> gdb/gdbarch.h                          |  53 +++

> gdb/gdbarch.sh                         |  36 ++

> gdb/linux-tdep.c                       | 356 ++++++++++++-------

> gdb/linux-tdep.h                       |   4 +

> gdb/nat/aarch64-mte-linux-ptrace.c     | 200 +++++++++++

> gdb/nat/aarch64-mte-linux-ptrace.h     |  50 +++

> gdb/printcmd.c                         | 468 ++++++++++++++++++++++++-

> gdb/remote.c                           | 230 ++++++++++++

> gdb/target-delegates.c                 |  84 +++++

> gdb/target.h                           |  25 ++

> gdb/testsuite/gdb.arch/aarch64-mte.c   | 107 ++++++

> gdb/testsuite/gdb.arch/aarch64-mte.exp | 371 ++++++++++++++++++++

> gdb/testsuite/gdb.base/memtag.c        |  22 ++

> gdb/testsuite/gdb.base/memtag.exp      |  64 ++++

> gdb/testsuite/lib/gdb.exp              |  16 +

> gdb/valprint.h                         |   1 +

> gdbserver/Makefile.in                  |   1 +

> gdbserver/configure.srv                |   2 +

> gdbserver/linux-aarch64-ipa.cc         |   8 +-

> gdbserver/linux-aarch64-low.cc         |  89 ++++-

> gdbserver/linux-aarch64-tdesc.cc       |  10 +-

> gdbserver/linux-aarch64-tdesc.h        |   3 +-

> gdbserver/remote-utils.cc              |  40 +--

> gdbserver/remote-utils.h               |   2 +

> gdbserver/server.cc                    | 214 +++++++++++

> gdbserver/server.h                     |   3 +

> gdbserver/target.cc                    |  20 ++

> gdbserver/target.h                     |  17 +

> gdbsupport/rsp-low.cc                  |   2 +-

> include/elf/common.h                   |   3 +

> 49 files changed, 3421 insertions(+), 182 deletions(-)

> create mode 100644 gdb/arch/aarch64-mte-linux.c

> create mode 100644 gdb/arch/aarch64-mte-linux.h

> create mode 100644 gdb/features/aarch64-mte.c

> create mode 100644 gdb/features/aarch64-mte.xml

> create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.c

> create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.h

> create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.c

> create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.exp

> create mode 100644 gdb/testsuite/gdb.base/memtag.c

> create mode 100644 gdb/testsuite/gdb.base/memtag.exp

> 

> -- 

> 2.17.1

>
Eli Zaretskii via Gdb-patches July 17, 2020, 12:33 p.m. | #2
On 7/16/20 1:49 PM, Alan Hayward wrote:
> 

> 

>> On 15 Jul 2020, at 20:44, Luis Machado <luis.machado@linaro.org> wrote:

>>

>> This patch series implements general memory tagging support for GDB, as well

>> as an implementation for AArch64 Linux.

>>

>> Memory tagging improves memory safety by tagging various parts of memory and

>> raising exceptions when the allocation tag (the one associated with a range of

>> memory addresses) does not match the logical tag contained in a pointer that is

>> used to access the memory area.

>>

>> We already have an implementation of such a mechanism for sparc64 (ADI), but

>> it is target-specific and not exposed to the rest of GDB. This series aims to

>> make the infrastructure available to other targets that may wish to support

>> their specific memory tagging approaches. For AArch64 Linux this is called

>> MTE (Memory Tagging Extensions).

>>

>> The series is split into a set that deals with generic changes to GDB's

>> infrastructure (target methods, gdbarch hooks and remote packets), a set that

>> implements support for AArch64 Linux and one last set that implements new

>> commands, updates the documentation and adds tests.

>>

>> The goal is to make it so the architecture independent parts of GDB don't

>> need to interpret tag formats, given the formats are likely different

>> for each architecture.  For this reason, GDB will handle tags as a sequence of

>> bytes and will not assume a particular format.

>>

>> The architecture-specific code can handle the sequence of bytes appropriately.

> 

> I’ve reviewed earlier versions of this series, and my comments have been applied.

> I’ve still taken a look through each patch in this latest series, and I’m mostly

> happy now. Instead of replying to each patch in turn, these are my bulk set of

> comments:

> 

> [PATCH 01/23] New target methods for memory tagging support

> [PATCH 02/23] New gdbarch memory tagging hooks

> - Looks good to me.

> 

> [PATCH 03/23] Add GDB-side remote target support for memory tagging

> [PATCH 04/23] Unit testing for GDB-side remote memory tagging handling

> [PATCH 05/23] GDBserver remote packet support for memory tagging

> [PATCH 06/23] Unit tests for gdbserver memory tagging remote packets

> [PATCH 07/23] Documentation for memory tagging remote packets

> - Looks ok, but I’m not that familiar with the remote packet interface.

> Worth someone else looking over.

> 

> [PATCH 08/23] AArch64: Add MTE CPU feature check support

> [PATCH 09/23] AArch64: Add target description/feature for MTE registers

> [PATCH 10/23] AArch64: Add MTE register set support for GDB and gdbserver

> [PATCH 11/23] AArch64: Add MTE ptrace requests

> [PATCH 12/23] AArch64: Implement memory tagging target methods for AArch64

> [PATCH 13/23] Refactor parsing of /proc/<pid>/smaps

> [PATCH 14/23] AArch64: Implement the memory tagging gdbarch hooks

> [PATCH 15/23] AArch64: Add unit testing for logical tag set/get operations

> [PATCH 16/23] AArch64: Report tag violation error information

> [PATCH 17/23] AArch64: Add gdbserver MTE support

> - These all Look good to me. My only concern here is that the Linux kernel support

> is a WIP. But given GDB is the main user of these interfaces, and that you’ve been

> reviewing the Linux patches, then I’m happy as long as they have all been tested

> together.


I have exercised the GDB series with Catalin's kernel series under QEMU. 
So the GDB changes match what the kernel is exposing right now.

> 

> [PATCH 18/23] New mtag commands

> [PATCH 19/23] Documentation for the new mtag commands

> - I’m happy with the new commands. But would like to know what others think, and

> I’m not familiar enough with the implementation of the commands to do a detailed

> review.


Same here. The idea is to provide some basic commands as a first step. 
Other commands can be added as needed.

> 

> [PATCH 20/23] Extend "x" and "print" commands to support memory tagging

>   -  Am I correct in thinking that p/x cannot cause a segfault? (we don’t want

> one to happen)


They can run into a segfault if, for example, you invoke a function that 
segfaults. But they won't trigger one if you attempt to access variables 
using invalid tags. Those will only happen when the process itself 
causes a tag violation.

GDB strips the top byte of the pointer on memory operations as well, so 
the addresses will have no tags in most cases.

> 

> [PATCH 21/23] Document new "x" and "print" memory tagging extensions

> [PATCH 22/23] Add NEWS entry.

>   - Looks good (assuming the commands aren’t changed)

> 

> 

>>

>> Luis Machado (23):

>>   New target methods for memory tagging support

>>   New gdbarch memory tagging hooks

>>   Add GDB-side remote target support for memory tagging

>>   Unit testing for GDB-side remote memory tagging handling

>>   GDBserver remote packet support for memory tagging

>>   Unit tests for gdbserver memory tagging remote packets

>>   Documentation for memory tagging remote packets

>>   AArch64: Add MTE CPU feature check support

>>   AArch64: Add target description/feature for MTE registers

>>   AArch64: Add MTE register set support for GDB and gdbserver

>>   AArch64: Add MTE ptrace requests

>>   AArch64: Implement memory tagging target methods for AArch64

>>   Refactor parsing of /proc/<pid>/smaps

>>   AArch64: Implement the memory tagging gdbarch hooks

>>   AArch64: Add unit testing for logical tag set/get operations

>>   AArch64: Report tag violation error information

>>   AArch64: Add gdbserver MTE support

>>   New mtag commands

>>   Documentation for the new mtag commands

>>   Extend "x" and "print" commands to support memory tagging

>>   Document new "x" and "print" memory tagging extensions

>>   Add NEWS entry.

>>   Add memory tagging testcases

>>

>> gdb/Makefile.in                        |   3 +

>> gdb/NEWS                               |  32 ++

>> gdb/aarch64-linux-nat.c                | 121 ++++++-

>> gdb/aarch64-linux-tdep.c               | 330 ++++++++++++++++-

>> gdb/aarch64-tdep.c                     |  40 ++-

>> gdb/aarch64-tdep.h                     |  12 +-

>> gdb/arch-utils.c                       |  50 +++

>> gdb/arch-utils.h                       |  23 ++

>> gdb/arch/aarch64-mte-linux.c           |  70 ++++

>> gdb/arch/aarch64-mte-linux.h           |  66 ++++

>> gdb/arch/aarch64.c                     |   7 +-

>> gdb/arch/aarch64.h                     |   7 +-

>> gdb/configure.nat                      |   3 +-

>> gdb/configure.tgt                      |   1 +

>> gdb/doc/gdb.texinfo                    | 174 ++++++++-

>> gdb/features/Makefile                  |   1 +

>> gdb/features/aarch64-mte.c             |  14 +

>> gdb/features/aarch64-mte.xml           |  11 +

>> gdb/gdbarch.c                          | 137 ++++++++

>> gdb/gdbarch.h                          |  53 +++

>> gdb/gdbarch.sh                         |  36 ++

>> gdb/linux-tdep.c                       | 356 ++++++++++++-------

>> gdb/linux-tdep.h                       |   4 +

>> gdb/nat/aarch64-mte-linux-ptrace.c     | 200 +++++++++++

>> gdb/nat/aarch64-mte-linux-ptrace.h     |  50 +++

>> gdb/printcmd.c                         | 468 ++++++++++++++++++++++++-

>> gdb/remote.c                           | 230 ++++++++++++

>> gdb/target-delegates.c                 |  84 +++++

>> gdb/target.h                           |  25 ++

>> gdb/testsuite/gdb.arch/aarch64-mte.c   | 107 ++++++

>> gdb/testsuite/gdb.arch/aarch64-mte.exp | 371 ++++++++++++++++++++

>> gdb/testsuite/gdb.base/memtag.c        |  22 ++

>> gdb/testsuite/gdb.base/memtag.exp      |  64 ++++

>> gdb/testsuite/lib/gdb.exp              |  16 +

>> gdb/valprint.h                         |   1 +

>> gdbserver/Makefile.in                  |   1 +

>> gdbserver/configure.srv                |   2 +

>> gdbserver/linux-aarch64-ipa.cc         |   8 +-

>> gdbserver/linux-aarch64-low.cc         |  89 ++++-

>> gdbserver/linux-aarch64-tdesc.cc       |  10 +-

>> gdbserver/linux-aarch64-tdesc.h        |   3 +-

>> gdbserver/remote-utils.cc              |  40 +--

>> gdbserver/remote-utils.h               |   2 +

>> gdbserver/server.cc                    | 214 +++++++++++

>> gdbserver/server.h                     |   3 +

>> gdbserver/target.cc                    |  20 ++

>> gdbserver/target.h                     |  17 +

>> gdbsupport/rsp-low.cc                  |   2 +-

>> include/elf/common.h                   |   3 +

>> 49 files changed, 3421 insertions(+), 182 deletions(-)

>> create mode 100644 gdb/arch/aarch64-mte-linux.c

>> create mode 100644 gdb/arch/aarch64-mte-linux.h

>> create mode 100644 gdb/features/aarch64-mte.c

>> create mode 100644 gdb/features/aarch64-mte.xml

>> create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.c

>> create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.h

>> create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.c

>> create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.exp

>> create mode 100644 gdb/testsuite/gdb.base/memtag.c

>> create mode 100644 gdb/testsuite/gdb.base/memtag.exp

>>

>> -- 

>> 2.17.1

>>

>
John Baldwin July 17, 2020, 10:02 p.m. | #3
On 7/15/20 12:44 PM, Luis Machado via Gdb-patches wrote:
> This patch series implements general memory tagging support for GDB, as well

> as an implementation for AArch64 Linux.

> 

> Memory tagging improves memory safety by tagging various parts of memory and

> raising exceptions when the allocation tag (the one associated with a range of

> memory addresses) does not match the logical tag contained in a pointer that is

> used to access the memory area.

> 

> We already have an implementation of such a mechanism for sparc64 (ADI), but

> it is target-specific and not exposed to the rest of GDB. This series aims to

> make the infrastructure available to other targets that may wish to support

> their specific memory tagging approaches. For AArch64 Linux this is called

> MTE (Memory Tagging Extensions).

> 

> The series is split into a set that deals with generic changes to GDB's

> infrastructure (target methods, gdbarch hooks and remote packets), a set that

> implements support for AArch64 Linux and one last set that implements new

> commands, updates the documentation and adds tests.

> 

> The goal is to make it so the architecture independent parts of GDB don't

> need to interpret tag formats, given the formats are likely different

> for each architecture.  For this reason, GDB will handle tags as a sequence of

> bytes and will not assume a particular format.

> 

> The architecture-specific code can handle the sequence of bytes appropriately.


I only have a couple of thoughts but think this is fine overall.

- For patch 2, I'm not sure the address needs to be a 'struct value' as opposed
  to just being a CORE_ADDR?  The earlier reference I had made to storing tags
  with a value was more about having a way to bundle a tag together with the
  "normal" value at a given memory location, but not using a value to describe
  the address of a tag.

- One thing I do see is that this currently assumes only a single memory tag
  type for a given architecture, but there may be architectures in the future
  which have multiple types of tags.  For APIs we can always add that later
  if needed, but retroactively adding it to the remote protocol might prove
  more sticky.  One alternative might be to do something like

  qMemTags:<type>:<address>:<length>

  and similarly for QMemTags.

  For MTE <type> could be "MTE" or "mte".  In the case that an architecture
  provides multiple tag types, then <type> could be used to disambiguate.

- It might be better to not refer to tags specifically as "allocation tags"
  in the generic code like gdbarch.*.  I do think the 'mtag' commands are
  also still a bit MTE-specific, but that is probably fine for now.

- p/x is very nice

- Very orthogonal: in a branch I have a change to make
  gdbarch_handle_segmentation_fault more generic so it is not specific to
  SIGSEGV but is instead able to report information for any signal.  I
  will try to extract that as a separate RFC.

-- 
John Baldwin
Eli Zaretskii via Gdb-patches July 23, 2020, 1:59 p.m. | #4
Hi,

On 7/17/20 7:02 PM, John Baldwin wrote:
> On 7/15/20 12:44 PM, Luis Machado via Gdb-patches wrote:

>> This patch series implements general memory tagging support for GDB, as well

>> as an implementation for AArch64 Linux.

>>

>> Memory tagging improves memory safety by tagging various parts of memory and

>> raising exceptions when the allocation tag (the one associated with a range of

>> memory addresses) does not match the logical tag contained in a pointer that is

>> used to access the memory area.

>>

>> We already have an implementation of such a mechanism for sparc64 (ADI), but

>> it is target-specific and not exposed to the rest of GDB. This series aims to

>> make the infrastructure available to other targets that may wish to support

>> their specific memory tagging approaches. For AArch64 Linux this is called

>> MTE (Memory Tagging Extensions).

>>

>> The series is split into a set that deals with generic changes to GDB's

>> infrastructure (target methods, gdbarch hooks and remote packets), a set that

>> implements support for AArch64 Linux and one last set that implements new

>> commands, updates the documentation and adds tests.

>>

>> The goal is to make it so the architecture independent parts of GDB don't

>> need to interpret tag formats, given the formats are likely different

>> for each architecture.  For this reason, GDB will handle tags as a sequence of

>> bytes and will not assume a particular format.

>>

>> The architecture-specific code can handle the sequence of bytes appropriately.

> 

> I only have a couple of thoughts but think this is fine overall.

> 

> - For patch 2, I'm not sure the address needs to be a 'struct value' as opposed

>    to just being a CORE_ADDR?  The earlier reference I had made to storing tags

>    with a value was more about having a way to bundle a tag together with the

>    "normal" value at a given memory location, but not using a value to describe

>    the address of a tag.


The use of a value instead of a CORE_ADDR means we can pass in data 
without having to worry about limits of the underlying data type. If we 
have a data type of more than 16 bytes, we wouldn't have to worry about 
conversions, truncation etc.

For example, we may need to bump the data type to int128 to store 
addresses larger than 64-bit, but that data type may not be available 
everywhere.

LLDB has APInt's that can deal with integers of arbitrary size, but in 
GDB we don't have such a type. The closest is struct value.

> 

> - One thing I do see is that this currently assumes only a single memory tag

>    type for a given architecture, but there may be architectures in the future

>    which have multiple types of tags.  For APIs we can always add that later

>    if needed, but retroactively adding it to the remote protocol might prove

>    more sticky.  One alternative might be to do something like

> 

>    qMemTags:<type>:<address>:<length>

> 

>    and similarly for QMemTags.

> 

>    For MTE <type> could be "MTE" or "mte".  In the case that an architecture

>    provides multiple tag types, then <type> could be used to disambiguate.


That sounds reasonable, but I'd still like to leave the interpretation 
of the type field to the target-specific code. Remote stubs would just 
parse the field and pass it on to the target-specific layers.

Out of curiosity, what other types of tags do you think could be used in 
the future?

> 

> - It might be better to not refer to tags specifically as "allocation tags"

>    in the generic code like gdbarch.*.  I do think the 'mtag' commands are

>    also still a bit MTE-specific, but that is probably fine for now.


I'm open to suggestions, but right now the two candidates we have are 
ADI "versions" and MTE "tags".

We need a way to distinguish between the memory tags and the pointer 
tags. "mtag", "atag" and "ltag" are documented in the manual so 
developers can understand what their purpose is, even though those may 
not match their particular architecture naming scheme.

GDB can also put together aliases for the commands, so targets can 
define their own naming scheme for memory tagging commands.

> 

> - p/x is very nice

> 

> - Very orthogonal: in a branch I have a change to make

>    gdbarch_handle_segmentation_fault more generic so it is not specific to

>    SIGSEGV but is instead able to report information for any signal.  I

>    will try to extract that as a separate RFC


Sounds good. I'll rebase on top of that when it gets pushed.
Eli Zaretskii via Gdb-patches July 23, 2020, 2:59 p.m. | #5
Ping?

On 7/15/20 4:44 PM, Luis Machado wrote:
> This patch series implements general memory tagging support for GDB, as well

> as an implementation for AArch64 Linux.

> 

> Memory tagging improves memory safety by tagging various parts of memory and

> raising exceptions when the allocation tag (the one associated with a range of

> memory addresses) does not match the logical tag contained in a pointer that is

> used to access the memory area.

> 

> We already have an implementation of such a mechanism for sparc64 (ADI), but

> it is target-specific and not exposed to the rest of GDB. This series aims to

> make the infrastructure available to other targets that may wish to support

> their specific memory tagging approaches. For AArch64 Linux this is called

> MTE (Memory Tagging Extensions).

> 

> The series is split into a set that deals with generic changes to GDB's

> infrastructure (target methods, gdbarch hooks and remote packets), a set that

> implements support for AArch64 Linux and one last set that implements new

> commands, updates the documentation and adds tests.

> 

> The goal is to make it so the architecture independent parts of GDB don't

> need to interpret tag formats, given the formats are likely different

> for each architecture.  For this reason, GDB will handle tags as a sequence of

> bytes and will not assume a particular format.

> 

> The architecture-specific code can handle the sequence of bytes appropriately.

> 

> Luis Machado (23):

>    New target methods for memory tagging support

>    New gdbarch memory tagging hooks

>    Add GDB-side remote target support for memory tagging

>    Unit testing for GDB-side remote memory tagging handling

>    GDBserver remote packet support for memory tagging

>    Unit tests for gdbserver memory tagging remote packets

>    Documentation for memory tagging remote packets

>    AArch64: Add MTE CPU feature check support

>    AArch64: Add target description/feature for MTE registers

>    AArch64: Add MTE register set support for GDB and gdbserver

>    AArch64: Add MTE ptrace requests

>    AArch64: Implement memory tagging target methods for AArch64

>    Refactor parsing of /proc/<pid>/smaps

>    AArch64: Implement the memory tagging gdbarch hooks

>    AArch64: Add unit testing for logical tag set/get operations

>    AArch64: Report tag violation error information

>    AArch64: Add gdbserver MTE support

>    New mtag commands

>    Documentation for the new mtag commands

>    Extend "x" and "print" commands to support memory tagging

>    Document new "x" and "print" memory tagging extensions

>    Add NEWS entry.

>    Add memory tagging testcases

> 

>   gdb/Makefile.in                        |   3 +

>   gdb/NEWS                               |  32 ++

>   gdb/aarch64-linux-nat.c                | 121 ++++++-

>   gdb/aarch64-linux-tdep.c               | 330 ++++++++++++++++-

>   gdb/aarch64-tdep.c                     |  40 ++-

>   gdb/aarch64-tdep.h                     |  12 +-

>   gdb/arch-utils.c                       |  50 +++

>   gdb/arch-utils.h                       |  23 ++

>   gdb/arch/aarch64-mte-linux.c           |  70 ++++

>   gdb/arch/aarch64-mte-linux.h           |  66 ++++

>   gdb/arch/aarch64.c                     |   7 +-

>   gdb/arch/aarch64.h                     |   7 +-

>   gdb/configure.nat                      |   3 +-

>   gdb/configure.tgt                      |   1 +

>   gdb/doc/gdb.texinfo                    | 174 ++++++++-

>   gdb/features/Makefile                  |   1 +

>   gdb/features/aarch64-mte.c             |  14 +

>   gdb/features/aarch64-mte.xml           |  11 +

>   gdb/gdbarch.c                          | 137 ++++++++

>   gdb/gdbarch.h                          |  53 +++

>   gdb/gdbarch.sh                         |  36 ++

>   gdb/linux-tdep.c                       | 356 ++++++++++++-------

>   gdb/linux-tdep.h                       |   4 +

>   gdb/nat/aarch64-mte-linux-ptrace.c     | 200 +++++++++++

>   gdb/nat/aarch64-mte-linux-ptrace.h     |  50 +++

>   gdb/printcmd.c                         | 468 ++++++++++++++++++++++++-

>   gdb/remote.c                           | 230 ++++++++++++

>   gdb/target-delegates.c                 |  84 +++++

>   gdb/target.h                           |  25 ++

>   gdb/testsuite/gdb.arch/aarch64-mte.c   | 107 ++++++

>   gdb/testsuite/gdb.arch/aarch64-mte.exp | 371 ++++++++++++++++++++

>   gdb/testsuite/gdb.base/memtag.c        |  22 ++

>   gdb/testsuite/gdb.base/memtag.exp      |  64 ++++

>   gdb/testsuite/lib/gdb.exp              |  16 +

>   gdb/valprint.h                         |   1 +

>   gdbserver/Makefile.in                  |   1 +

>   gdbserver/configure.srv                |   2 +

>   gdbserver/linux-aarch64-ipa.cc         |   8 +-

>   gdbserver/linux-aarch64-low.cc         |  89 ++++-

>   gdbserver/linux-aarch64-tdesc.cc       |  10 +-

>   gdbserver/linux-aarch64-tdesc.h        |   3 +-

>   gdbserver/remote-utils.cc              |  40 +--

>   gdbserver/remote-utils.h               |   2 +

>   gdbserver/server.cc                    | 214 +++++++++++

>   gdbserver/server.h                     |   3 +

>   gdbserver/target.cc                    |  20 ++

>   gdbserver/target.h                     |  17 +

>   gdbsupport/rsp-low.cc                  |   2 +-

>   include/elf/common.h                   |   3 +

>   49 files changed, 3421 insertions(+), 182 deletions(-)

>   create mode 100644 gdb/arch/aarch64-mte-linux.c

>   create mode 100644 gdb/arch/aarch64-mte-linux.h

>   create mode 100644 gdb/features/aarch64-mte.c

>   create mode 100644 gdb/features/aarch64-mte.xml

>   create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.c

>   create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.h

>   create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.c

>   create mode 100644 gdb/testsuite/gdb.arch/aarch64-mte.exp

>   create mode 100644 gdb/testsuite/gdb.base/memtag.c

>   create mode 100644 gdb/testsuite/gdb.base/memtag.exp

>
John Baldwin July 23, 2020, 4:48 p.m. | #6
On 7/23/20 6:59 AM, Luis Machado wrote:
>> - One thing I do see is that this currently assumes only a single memory tag

>>    type for a given architecture, but there may be architectures in the future

>>    which have multiple types of tags.  For APIs we can always add that later

>>    if needed, but retroactively adding it to the remote protocol might prove

>>    more sticky.  One alternative might be to do something like

>>

>>    qMemTags:<type>:<address>:<length>

>>

>>    and similarly for QMemTags.

>>

>>    For MTE <type> could be "MTE" or "mte".  In the case that an architecture

>>    provides multiple tag types, then <type> could be used to disambiguate.

> 

> That sounds reasonable, but I'd still like to leave the interpretation 

> of the type field to the target-specific code. Remote stubs would just 

> parse the field and pass it on to the target-specific layers.


Agreed.

> Out of curiosity, what other types of tags do you think could be used in 

> the future?


The Morello prototype architecture includes "cheri" memory tags on aarch64,
and while Morello doesn't include MTE, it is within the realm of possibility
that a future aarch64 architecture will contain both MTE and CHERI and will
thus include two sets of memory tags.  One option would be for this to be
provided as a special "combined" tag since MTE and CHERI both have the same
tag stride (16 byte boundaries), but that might be more fragile to implement
compared to having them named separately.
 
>> - It might be better to not refer to tags specifically as "allocation tags"

>>    in the generic code like gdbarch.*.  I do think the 'mtag' commands are

>>    also still a bit MTE-specific, but that is probably fine for now.

> 

> I'm open to suggestions, but right now the two candidates we have are 

> ADI "versions" and MTE "tags".


I guess I view "tags" as a generic way of having a parallel address space
of memory (and in some cases registers) where metadata about the "normal"
memory or register contents are stored.  In that context "tag" is the
general name for metadata and MTE happens to use the general name directly.
I would perhaps just call them "tags" or "memory tags" in gdbarch, but that's
a minor quibble.

> We need a way to distinguish between the memory tags and the pointer 

> tags. "mtag", "atag" and "ltag" are documented in the manual so 

> developers can understand what their purpose is, even though those may 

> not match their particular architecture naming scheme.

> 

> GDB can also put together aliases for the commands, so targets can 

> define their own naming scheme for memory tagging commands.


That's fine.

-- 
John Baldwin
Eli Zaretskii via Gdb-patches July 24, 2020, 4:10 p.m. | #7
(if it wasn't already mentioned, I'm working on the lldb side of things)

> - One thing I do see is that this currently assumes only a single memory tag

  type for a given architecture, but there may be architectures in the future
  which have multiple types of tags.

+1 for this idea.

The use case seems somewhat distant now but it'll save us doing
fragile heuristics on the packed tags to differentiate them if it does
happen. (and the tags potentially being a pattern to be repeated makes
this even less viable)



On Thu, 23 Jul 2020 at 17:49, John Baldwin <jhb@freebsd.org> wrote:
>

> On 7/23/20 6:59 AM, Luis Machado wrote:

> >> - One thing I do see is that this currently assumes only a single memory tag

> >>    type for a given architecture, but there may be architectures in the future

> >>    which have multiple types of tags.  For APIs we can always add that later

> >>    if needed, but retroactively adding it to the remote protocol might prove

> >>    more sticky.  One alternative might be to do something like

> >>

> >>    qMemTags:<type>:<address>:<length>

> >>

> >>    and similarly for QMemTags.

> >>

> >>    For MTE <type> could be "MTE" or "mte".  In the case that an architecture

> >>    provides multiple tag types, then <type> could be used to disambiguate.

> >

> > That sounds reasonable, but I'd still like to leave the interpretation

> > of the type field to the target-specific code. Remote stubs would just

> > parse the field and pass it on to the target-specific layers.

>

> Agreed.

>

> > Out of curiosity, what other types of tags do you think could be used in

> > the future?

>

> The Morello prototype architecture includes "cheri" memory tags on aarch64,

> and while Morello doesn't include MTE, it is within the realm of possibility

> that a future aarch64 architecture will contain both MTE and CHERI and will

> thus include two sets of memory tags.  One option would be for this to be

> provided as a special "combined" tag since MTE and CHERI both have the same

> tag stride (16 byte boundaries), but that might be more fragile to implement

> compared to having them named separately.

>

> >> - It might be better to not refer to tags specifically as "allocation tags"

> >>    in the generic code like gdbarch.*.  I do think the 'mtag' commands are

> >>    also still a bit MTE-specific, but that is probably fine for now.

> >

> > I'm open to suggestions, but right now the two candidates we have are

> > ADI "versions" and MTE "tags".

>

> I guess I view "tags" as a generic way of having a parallel address space

> of memory (and in some cases registers) where metadata about the "normal"

> memory or register contents are stored.  In that context "tag" is the

> general name for metadata and MTE happens to use the general name directly.

> I would perhaps just call them "tags" or "memory tags" in gdbarch, but that's

> a minor quibble.

>

> > We need a way to distinguish between the memory tags and the pointer

> > tags. "mtag", "atag" and "ltag" are documented in the manual so

> > developers can understand what their purpose is, even though those may

> > not match their particular architecture naming scheme.

> >

> > GDB can also put together aliases for the commands, so targets can

> > define their own naming scheme for memory tagging commands.

>

> That's fine.

>

> --

> John Baldwin