[PATCH 0/7] RFC Memory tagging support

[H.J. Lu]

On Tue, Jun 16, 2020 at 2:36 AM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> 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

Without the marker, MTE is just another debug tool which I don't think
glibc needs.  With the marker, MTE can be used to protect glibc.

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

Initially the marker needs to be added explicitly by programmers, just
like we are enabling MTE in some glibc files.

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

But, MTE can be used to protect glibc. We may not be able to do it
today.  But an MTE marker can help us get there.

-- 
H.J.