[PATCH 0/7] RFC Memory tagging support
Tue Jun 16 14:27:23 GMT 2020
On Tue, Jun 16, 2020 at 7:14 AM Richard Earnshaw (lists)
> On 16/06/2020 14:31, H.J. Lu via Libc-alpha wrote:
> > On Tue, Jun 16, 2020 at 1:14 AM Szabolcs Nagy <email@example.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.
More information about the Libc-alpha