[PATCH] aarch64: MTE compatible strchrnul

Szabolcs Nagy szabolcs.nagy@arm.com
Wed Jun 3 15:03:16 GMT 2020


The 06/03/2020 15:53, Szabolcs Nagy wrote:
> 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).

this is not entirely true: (2) can be fixed at runtime
by keeping tags but turning tag checks off (it's a per
thread setting so a bit tricky to do across all threads),
but (1) cannot be fixed at runtime: if there are tagged
pointers already being passed around we cannot get rid
of them, so we have to reject the incompatible library.

we could have separate markup for problems (1) and (2)
but neither of them is easily discoverable by the compiler
(well conforming c code is not supposed to do either),
so i don't know how the markup would be added to object
files in a reliable way.

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

-- 


More information about the Libc-alpha mailing list