[PATCH 0/7] RFC Memory tagging support

[H.J. Lu]

On Tue, Jun 16, 2020 at 8:10 AM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 16/06/2020 15:52, H.J. Lu via Libc-alpha wrote:
> > On Tue, Jun 16, 2020 at 7:34 AM Richard Earnshaw (lists)
> > <Richard.Earnshaw@arm.com> wrote:
> >>
> >> On 16/06/2020 15:27, H.J. Lu wrote:
> >>> On Tue, Jun 16, 2020 at 7:14 AM Richard Earnshaw (lists)
> >>> <Richard.Earnshaw@arm.com> wrote:
> >>>>
> >>>> On 16/06/2020 14:31, H.J. Lu via Libc-alpha wrote:
> >>>>> On Tue, Jun 16, 2020 at 1:14 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >>>>>>
> >>>>>> The 06/15/2020 12:18, H.J. Lu wrote:
> >>>>>>> I think we need a marker to indicate an object is MTE compatible.
> >>>>>>
> >>>>>> i expect users to only able to discover tag-unsafety
> >>>>>> issues in applications at runtime and even if there
> >>>>>> is static information in binaries that's usually too
> >>>>>> late to do anything useful about it (other than fail).
> >>>>>>
> >>>>>> so i think an initial implementation that is off by
> >>>>>> default but can be turned on with an env var makes
> >>>>>> sense, but i agree that to turn tagging on by default
> >>>>>> some markings will be needed such that tag-unsafe
> >>>>>> applications continue to work (if possible).
> >>>>>
> >>>>> MTE isn't just another debugging tool.  Otherwise, we wouldn't
> >>>>> want it in glibc.
> >>>>
> >>>> That doesn't follow from your claim.  eg we have MALLOC_CHECK - that's a
> >>>> debugging tool and we have it in glibc.
> >>>>
> >>>>> Since we are enabling MTE in some object files,
> >>>>> at least we should mark them as MTE enabled.
> >>>>
> >>>> When we start using MTE to colour stack objects, yes, we'll need to mark
> >>>> object files that use it (they require longjmp to clean up the stack
> >>>> colouring, for example).  Until then, I disagree.  You do not need to
> >>>> mark every object file as compatible with *heap* objects that have been
> >>>> coloured.  If you disagree please provide a concrete example.
> >>>>
> >>>
> >>> I can image MTE is always on by default, starting with glibc.
> >>
> >> I think that's unlikely, even with lazy faulting because the HW overhead
> >> is not zero.  At some point, it might be that we'd want to enable it
> >> semi-randomly when running some programs (I've heard of some OSes
> >> planning to do something like that for telemetry type monitoring), but
> >> we're a long way from that; and what's more, we're a long way from
> >> really having a list of what's safe and what's not.  So until then,
> >> arbitrarily marking objects to say they're safe when we don't know that
> >> will just create a marker that has zero use, because we won't be able to
> >> rely on it.
> >
> > Yes, there will be overhead.  But some users will be OK with it.
> >
> >> If you're going to have markers, you'd better be 100% sure what it's
> >> telling you is right, or it's not worth the bits you've spent on it.
> >>
> >
> > There will be mistakes.  It doesn't mean that we shouldn't do it.
> >
> >
>
> But we shouldn't be doing it NOW, at least, not until we have a MUCH
> better idea of what constitutes a safe vs an unsafe program and can give
> clear advice to developers (or automate the tools) to do this sensibly.
>  Anything else would be a random guess and create more problems than it
> solves.

If we don't plan it from the very beginning, it may never happen.

-- 
H.J.