Re: [PATCH v2 20/24] Documentation for the new mtag commands

[Luis Machado via Gdb-patches <gdb-patches@sourceware.org>]

On 10/23/20 3:35 AM, Eli Zaretskii wrote:
>> Date: Thu, 22 Oct 2020 17:00:10 -0300
>> From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
>> Cc: david.spickett@linaro.org
>>
>> +Memory tagging is a memory protection technology that uses tags to validate
>> +memory accesses through pointers.  The pointer tag must match the memory tag
>> +for the memory access to be validated.
>                           ^^^^^^^^^^^^^^^
> I guess "to be valid" is more clear, as "validated" can be interpreted
> as the process of validation, not its result.
> 

That makes sense. I've updated the text to say "valid".

>> +There are two types of tags: logical and allocation.  A logical tag is
>> +stored in the pointers themselves.  A allocation tag is the tag associated
>                                         ^                   ^^^
> "An" and "a"
> 

Fixed.

> Also, this text fails to explain that (AFAIU) these 2 types of tags
> work together to allow the access validation.  IOW, both types need to
> be present for the mechanism to work.  I originally interpreted the
> text as meaning that tags come in 2 flavors, depending on how the
> hardware implemented the facility.
> 

I can add a bit more text describing that. But things can get a bit 
confusing in the future as we support more tags of different types. For 
example, CHERI capability tags are similar to logical tags, but you 
can't set those.

But, in general, there will always be a memory-side tag against which a 
logical tag (contained in a pointer, for example) will be matched against.

>> +@kindex mtag setltag
>> +@item mtag setltag @var{address_expression} @var{tag_bytes}
>> +Print the address given by @var{address_expression}, augmented with a logical
> 
> It is strange for a command whose name is "set..." to print
> something.  I'd expect it to set something instead.  is the above
> description correct?
> 

Yes. This is one area that I'd welcome some discussion/feedback.

We don't always have a modifiable value as an argument to the "mtag 
setltag" command. We could have a constant value, a read-only value, 
some reference or some expression containing multiple pointers.

Plus, the most natural way to modify a value in GDB is through the 
existing "set variable" command.

The main goal is to be able to augment a particular address with a given 
logical tag. That augmented value can then be used to set a particular 
pointer or value. It will be stored in the history anyway, so that's 
already a value that you can use.

There won't be much reason to set logical tags other than if you're 
chasing bugs and trying to cause one. It is one additional knob so that 
you won't need to craft the tagged pointer by hand.

>> +@item mtag setatag @var{starting_address} @var{length} @var{tag_bytes}
>> +Set the allocation tag(s) for memory range @r{[}@var{starting_address},
>> +@var{starting_address} + @var{length}@r{)} to @var{tag_bytes}.
> 
> This is what I'd expect from setltag to do. >

Yeah. But contrary to the logical tag, we can always set the allocation 
tag in memory. Given a particular expression that gets evaluated to an 
address, we can always set a tag at that address. There's no 
lval/non-lval issues here.

With logical tags this is only possible if you evaluate the expression 
to an address and then tweak the resulting address to contain a 
particular logical tag. That's why we print the resulting adjusted 
address as opposed to modifying some pointer/variable.

>> +@kindex mtag check
>> +@item mtag check @var{address_expression}
>> +Check that the logical tag stored at the address given by
>> +@var{address_expression} matches the allocation tag for the same address.
> 
> This test should say that this check performs the same validation as
> is done in hardware when memory is accessed through a pointer.  Saying
> that (assuming I understood correctly) will go a long way towards
> causing this facility to make much more sense to the reader.

Does it make it more clear if I add the following:

"This essentially emulates the hardware validation that is done when 
tagged memory is accessed through a pointer, but does not cause a memory 
fault as it would during hardware validation.

It can be used to inspect potential memory tagging violations in the 
running process, before any faults get triggered."