[PATCH 0/7] RFC Memory tagging support

[Richard Earnshaw (lists)]

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.

R.

> -- 
> H.J.