[PATCH 0/7] RFC Memory tagging support

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Mon Jun 15 16:51:12 GMT 2020

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!

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.



More information about the Libc-alpha mailing list