[PATCH 0/7] RFC Memory tagging support

[Szabolcs Nagy]

The 06/16/2020 09:33, H.J. Lu via Libc-alpha wrote:
> 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.

the two main usage of heap tagging is debugging
and security hardening.

for debugging the env var is fine.

for security if we tag things as mte unsafe
we get a system where all the relevant
applications are marked unsafe and mte is not
enabled (the main culprits for mte unsafety are
the complex runtimes that we want to protect:
python, browsers, ..., they are also the cases
where marking does not really work: they dlopen
their dependencies, so they fail at runtime
with or without a marking)

i think heap tagging is different from shadow
stack in that 99% of heap tagging failures are
not some obscure hack that is valid but happens
to be incompatible with the feature, but very
likely a bug in the code that is undefined by
the language standard and thus the compiler
can already break the code if it was smarter.
(and often it may be exploitable and then we
definitely don't want to use marking, but
fix the actual bug)

i don't know how the shadow stack marking
works: none of the asm files in glibc are
marked, do you force the marking on in the
linker? or the assembler? either way i don't
think it is a very reliable or easy to
maintain mechanism. but i agree that we will
need some mechanism to keep existing binaries
working (so users don't need to make a choice
between secure but broken or insecure but
working setup)