[PATCH 0/7] RFC Memory tagging support

[Szabolcs Nagy]

The 06/15/2020 08:37, H.J. Lu via Libc-alpha wrote:
> On Mon, Jun 15, 2020 at 8:11 AM Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
> >
> > On 15/06/2020 16:03, H.J. Lu wrote:
> > > On Mon, Jun 15, 2020 at 7:43 AM Richard Earnshaw <rearnsha@arm.com> wrote:
> > >>
> > >> Last year I posted a preliminary set of patches for discussion
> > >> purposes on adding support for tagged memory to glibc.  This version
> > >> polishes that to the point where I believe it is now deployable.
> > >>
> > >> The first four patches are generic changes, the final three add the
> > >> aarch64 specific code.
> > >>
> > >> The first patch simply adds a new configuration option to the build
> > >> system which can be turned on with the option --enable-memory-tagging.
> > >> The default at present is 'no'.
> > >>
> > >> The second patch adds a glibc tunable that can be used at run-time to
> > >> enable the feature (the default again, is disabled).  This tunable
> > >> would be always present, but have no effect on systems lacking support
> > >> for memory tagging.  I've structured the tunable as a bit-mask of
> > >> features that can be used with memory tagging, though at present only
> > >> two bits have defined uses.
> > >>
> > >> The third patch is the meat of the changes; it adds the changes to the
> > >> malloc APIs.  I've tried as far as possible to ensure that when memory
> > >> tagging is disabled, there is no change in behaviour, even when the
> > >> memory tagging is configured into the library, but there are
> > >> inevitably a small number of changes needed in the optimizations that
> > >> calloc performs since tagging would require that all the tags were
> > >> correctly set, even if the memory does not strictly have to be zeroed.
> > >> I've made use of function pointers in the code, much the same way as
> > >> the morecore hook is used, so that when tagging is disabled, the
> > >> functions called are the same as the traditional operations; this also
> > >> ensures that glibc does not require any internal ifunc resolution in
> > >> order to work.
> > >>
> > >> The fourth patch adds support for the new prctl operations that are
> > >> being proposed to the linux kernel.  The kernel changes are to a
> > >> generic header and this patch mirrors that design decision in glibc.
> > >>
> > >> The fifth patch is a place-holder, so that this series of changes is
> > >> stand-alone.  Work is already underway to change the string operations
> > >> to be MTE safe without losing too much in the way of performance.  I
> > >> expect this patch to be removed entirely before the series is
> > >> committed.
> > >>
> > >> The final two patches add the remaining aarch64 support.  The first
> > >> adds the support code to examine the tunable and HW caps; and enable
> > >> memory tagging in the kernel as needed.  The second adds the final
> > >> pieces needed to support memory tagging in glibc.
> > >>
> > >
> > > Obviously, pointer comparison and algorithm will be impacted by MTE.
> > > From what you are proposing, only parts of glibc will be MTE compatible.
> > > Is this correct?
> > >
> >
> > Only *undefined* pointer comparisons will be impacted, such as comparing
> > objects from different allocations.
> >
> > Within an allocation comparisons are fine.  And also, pointer
> > equivalence is fine as well.
> >
> 
> Is "ptr1 - ptr2" valid to compute the distance between 2 pointers?

in iso c that's only valid within the same object.

(but e.g. gcc tries to detect which way the stack grows
by comparing stack pointers across stack frames: that's
not legal in c, and does not work if stack objects are
tagged with mte, this patch set is for heap tagging though)