[PATCH 0/7] RFC Memory tagging support

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Tue Jun 16 09:36:47 GMT 2020


On 15/06/2020 20:18, H.J. Lu via Libc-alpha wrote:
> On Mon, Jun 15, 2020 at 11:41 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>
>> The 06/15/2020 11:05, Paul Eggert wrote:
>>> On 6/15/20 9:51 AM, Richard Earnshaw (lists) wrote:
>>>> In practice it will work because objects passed to memmove will have to
>>>> have a single colour,
>>>
>>> Does this mean all stack and heap objects visible to the C programmer must have
>>> the same tag? This surprises me, as I thought part of the idea was to assign
>>> tags randomly.
>>
>> the check works for non-overlapping objects with
>> or without tagging the same way, so different
>> heap allocations can have different color.
>>
>> for overlapping objects the pointers must have
>> the same tag for the check to work, so single
>> heap allocations must have a single color.
>> this is guaranteed by the proposed design.
>>
>> (in case of heap allocation it would be
>> difficult to do otherwise, but e.g. stack
>> tagging could try to color different fields
>> in a struct differently and then memmove
>> would fail to detect an overlapping copy).
> 
> I think we need a marker to indicate an object is MTE compatible.
> 

I think that's inverted.  Firstly, we would then need to recompile
everything in order to use MTE; that's highly undesirable, especially
when it's largely unnecessary.  Secondly, how would a compiler know?  It
generally can't see when a programmer isn't conforming fully to the
standard - so you'd have to trust the user and just put in the tag.
Quite frankly, that's just silly.

There are a small number of programs that do violate the principles that
underlying tagging - sadly Python's memory management code is one of
them - it has objects that are a mix of malloc'd objects and objects
it's doled out from its own heap, but it assumes it can just grub around
in a memory page to find out which - yuck.  Ideally, these would be
marked in some way so that we never enabled MTE in those cases.  But at
present, I don't see that as urgent.

Remember, MTE is primarily a *debugging* aid, intended to help identify
issues such as buffer overruns and other allocation issues such as
use-after free or double free.  It doesn't have to be on all the time,
so if some programs won't work with it that's not a fatal issue - just
don't turn it on in that case.

R.


More information about the Libc-alpha mailing list