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

[Luis Machado <luis.machado@linaro.org>]

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.