[PATCH] aarch64: MTE compatible strchrnul

[Szabolcs Nagy]

The 06/03/2020 11:33, Adhemerval Zanella via Libc-alpha wrote:
> On 03/06/2020 11:24, Florian Weimer via Libc-alpha wrote:
> > * Andrea Corallo:
> >> Florian Weimer <fweimer@redhat.com> writes:
> >>> As a very high-level comment, I would expect some sort of markup in the
> >>> file that this implementation is now MTE-safe, similar to what we have
> >>> for executable stacks.
> >>>
> >>> Or do you plan to handle that in some other fashion?
> >>>
> >>> Thanks,
> >>> Florian
> >>
> >> Hi Florian,
> >>
> >> Now the only markup is the comment on the top of the file stating the
> >> MTE compatibility of the routine.
> >>
> >> I'm not aware of how this marking is done for executable stacks, perhaps
> >> could you give an hook on where to look for?
> > 
> > Typically, the -z noexecstack flag or a special .note.GNU-stack section
> > is used for that.
> > 
> >> Just to make sure we are one the same page wanted to add: these
> >> functions are supposed to be backward compatible with what they are
> >> replacing, so I'm not sure a marking is necessary.
> > 
> > It's MTE that isn't backwards-compatible without such markup.
> 
> Afaiu there is no need to add any marking for MTE, the main difference
> it enforce 16-byte granularity read. I think you are confusing with
> BTI, which does require the GNU note.

in principle existing binaries may not be mte safe:

(1) the top byte may be used by user code,
(2) page size granularity may be assumed for memory protection.

so it is a valid question if we want to mark binaries that
are mte-safe to make mte an opt-in feature.

the problem is that then we cannot use heap tagging for debugging
heap corruption problems in existing binaries. so even if we
apply an mte markup we have to allow the user to override that.

we probably don't want heap tagging on by default since there
is an overhead so in the end it will be a user choice if mte
is enabled or not.

the difference compared to noexecstack is that the runtime can
fall back to executable stack if there are non-marked binaries,
but with mte once it's on the runtime cannot fall back, just
reject incompatible binaries (and it has to be on very early:
before malloc calls are made).

i don't know if it makes sense to introduce an object markup just
for aborting / rejecting loading libraries when the user asked
for mte.