Programming model for tagged addresses

[Florian Weimer <fweimer@redhat.com>]

This is related to this bug:

  memmove doesn't work with tagged address
  <https://sourceware.org/bugzilla/show_bug.cgi?id=27828>

The bug is about detecting memory region overlap in the presence of
tagged addresses.  This problem exists also with address tagging
emulation using alias mappings.

If tags are fixed at allocation, I do not think these comparisons are a
problem.  The argument goes like this: Backwards vs forwards copy only
matters in case of overlap.  All pointers within the same top-level
object have the same tag, so the existing comparisons are fine.
Overlapping memmove between different top-level objects cannot happen
because top-level objects do not overlap.  So you have to copy multiple
objects to get an overlap, but that copies data between the objects as
well, which is necessarily undefined.

Things change when applications are expected to flip tag bits as they
see fit, including for pointers to subjects.  This leads to the question
whether it's valid to pass such tag-altered pointers to glibc functions
and system calls.  Many objects have significant addresses (mutex and
other synchronization objects, stdio streams), so the answer to that
isn't immediately obvious.

The next question is tag bits coming from glibc and the kernel are
always zero initially.  For example, for malloc, we currently use two
bits in the heap to classify chunks (main arena, non-main arena, mmap).
These bits do not change after allocation, so it is tempting to put them
into the pointer itself.  But this means that some of the tag bits are
lost for application use.

Thanks,
Florian