[PATCH 0/7] RFC Memory tagging support

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Tue Jun 16 14:34:33 GMT 2020

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.

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.


> -- 
> H.J.

More information about the Libc-alpha mailing list