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

Luis Machado via Gdb-patches
2020-10-23T14:33:46Z

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."