Re: [PATCH] [AArch64] MTE corefile support

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

Hi John,

On 5/21/21 2:20 PM, John Baldwin wrote:
> On 5/21/21 8:30 AM, Luis Machado wrote:
>> Hi Alan,
>>
>> On 5/21/21 12:12 PM, Alan Hayward wrote:
>>>
>>>
>>>> On 18 May 2021, at 21:20, Luis Machado <luis.machado@linaro.org> wrote:
>>>>
>>>> Teach GDB how to dump memory tags when using the gcore command and how
>>>> to read them back from a core file generated via gcore or the kernel.
>>>>
>>>> Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped 
>>>> to its
>>>> own NT_MEMTAG note. A section named ".memtag" is created for each of 
>>>> those
>>>> when reading the core file back.
>>>>
>>>> Dumping memory tags
>>>> -
>>>>
>>>> When using the gcore command to dump a core file, GDB will go 
>>>> through the maps
>>>> in /proc/<pid>/smaps looking for tagged ranges. Each of those 
>>>> entries gets
>>>> passed to an arch-specific gdbarch hook that generates a vector of 
>>>> blobs of
>>>> memory tag data that are blindly put into a NT_MEMTAG note.
>>>>
>>>> The vector is used because we may have, in the future,  multiple tag 
>>>> types for
>>>> a particular memory range.
>>>>
>>>> Each of the NT_MEMTAG notes have a generic header and a 
>>>> arch-specific header,
>>>> like so:
>>>>
>>>> struct tag_dump_header
>>>> {
>>>>    uint16_t format; // Only NT_MEMTAG_TYPE_AARCH_MTE at present
>>>>    uint64_t start_vma;
>>>>    uint64_t end_vma;
>>>> };
>>>>
>>>> struct tag_dump_mte
>>>> {
>>>>    uint16_t granule_byte_size;
>>>>    uint16_t tag_bit_size;
>>>>    uint16_t __unused;
>>>> };
>>>>
>>>> The only bits meant to be generic are the tag_dump_format, start_vma 
>>>> and
>>>> end_vma fields.
>>>>
>>>> The format-specific data is supposed to be opaque and only useful 
>>>> for the
>>>> arch-specific code.
>>>>
>>>> We can extend the format in the future to make room for other memory 
>>>> tag
>>>> layouts.
>>>>
>>>
>>> This is a wider question than this patch - but is there someplace 
>>> this format will
>>> be documented? Ideally either Linux or GDB needs something written 
>>> down in
>>> text format.
>>>
>>> A few nits below too, but mostly looks fine.
>>
>> Yes. I'm still thinking whether this should go into the Linux Kernel's
>> documentation or somewhere in the GDB manual.
>>
>> Given GDB reads core files generated by the Linux Kernel and also
>> creates cores files itself, I'm thinking it may be best to put it in the
>> GDB manual.
>>
>> I want to wait for possible feedbacks about the format before we
>> document how it will look like in the manual.
> 
> Also, NT_MEMTAG is not inherently OS specific and I plan to reuse whatever
> format is used here for CHERI tags on RISC-V and Morello in CheriBSD (a
> CHERI-aware version of FreeBSD).  If someone adds MTE support in FreeBSD
> that would use the same format as well.  To that end, I think we should
> aim to have the tag "type" values be OS independent (so just depending
> on the arch).  Having an actual value of NT_MEMTAG that is portable is
> harder as various OS's already have conflicting NT_* namespaces.  If we

Just recently Andrew added the NT_GDB_TDESC note type, which is supposed 
to be OS-independent. The value for that (0xff000000) was picked out of 
a range that doesn't overlap with existing OS-specific definitions.

I'm doing the same for NT_MEMTAG. You can use it for any OS (or 
bare-metal), as it doesn't have anything Linux-specific.

> wanted something truly independent we could perhaps choose a neutral
> note name (e.g. "memtag" instead of "Linux", "CORE", or "FreeBSD") and

I'm using CORE right now. But we could change it to something else if 
needed. Isn't CORE something any OS can work with?

> then the note type could instead take the place of the type of tag,
> but that may be overly complicated compared to just having OS-specific
> NT_MEMTAG values.
>