[PATCH 0/7] RFC Memory tagging support

H.J. Lu hjl.tools@gmail.com
Thu Jun 18 20:30:13 GMT 2020


On Wed, Jun 17, 2020 at 3:53 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> 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.

Yes, marking is intended for security hardening.  We need to plan
ahead.

> for debugging the env var is fine.

Agree.

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

We need to classify different taggings so that
some or all taggings can be enabled.

> 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

We do it in compiler and assembler with help from
compiler.   Since shadow stack is compatible with
most of codes, we simply add the shadow stack
marker with -fcf-protections.  The main problem is
JIT, which needs to unwind shadow stack when
stack frames are skipped.

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

Marker should be accurate.  Otherwise it won't work.

-- 
H.J.


More information about the Libc-alpha mailing list