[PATCH 0/7] RFC Memory tagging support
Richard Earnshaw (lists)
Mon Jun 15 15:11:32 GMT 2020
On 15/06/2020 16:03, H.J. Lu wrote:
> On Mon, Jun 15, 2020 at 7:43 AM Richard Earnshaw <email@example.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
>> 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.
More information about the Libc-alpha