[PATCH 0/7] RFC Memory tagging support

H.J. Lu hjl.tools@gmail.com
Mon Jun 15 17:46:17 GMT 2020


On Mon, Jun 15, 2020 at 9:51 AM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 15/06/2020 17:40, H.J. Lu via Libc-alpha wrote:
> > On Mon, Jun 15, 2020 at 9:30 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >>
> >> 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)
> >
> > memmove in C has
> >
> > rettype
> > inhibit_loop_to_libcall
> > MEMMOVE (a1const void *a1, a2const void *a2, size_t len)
> > {
> >   unsigned long int dstp = (long int) dest;
> >   unsigned long int srcp = (long int) src;
> >
> >   /* This test makes the forward copying code be used whenever possible.
> >      Reduces the working set.  */
> >   if (dstp - srcp >= len) /* *Unsigned* compare!  */
> >
> > How does it work?
> >
>
> Well the code is technically undefined!

What does it mean to glibc?  Have you done an audit on glibc for this
issue?

> In practice it will work because objects passed to memmove will have to
> have a single colour, so the test will work correctly, though not for
> the reason the programmer thought.

Do you have a list of functions in glibc which allow more than one color?

-- 
H.J.


More information about the Libc-alpha mailing list