Re: [RFC] <sys/tagged-address.h>: An API for tagged address

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 02/12/2021 05:06, H.J. Lu via Libc-alpha wrote:
> On Fri, Feb 12, 2021 at 1:43 AM Florian Weimer <fweimer@redhat.com> wrote:
> > * H. J. Lu via Libc-alpha:
> > > On Thu, Feb 11, 2021 at 12:28 PM Joseph Myers <joseph@codesourcery.com> wrote:
> > >> On Thu, 11 Feb 2021, H.J. Lu via Libc-alpha wrote:
> > >>
> > >> > An API for tagged address:
> > >>
> > >> Please write a longer commit message, discussing what "tagged address" is,
> > >> which architectures have such a thing (the API should try to cover
> > >> whatever is common between architectures as far as possible - is this
> > >> meant to relate to AArch64 MTE, how does it relate to the MTE code we
> > >
> > > This API is for Intel LAM:
> > >
> > > https://www.phoronix.com/scan.php?page=news_item&px=Intel-LAM-Glibc#:~:text=Intel%20Linear%20Address%20Masking%20(LAM,bit%20linear%20addresses%20for%20metadata.&text=With%20LAM%20enabled%2C%20the%20processor,linear%20address%20to%20access%20memory.
> > >
> > > and ARM TBI:
> > >
> > > https://en.wikichip.org/wiki/arm/tbi
> >
> > Do the setters/getters change process or thread properties?
> 
> On x86-64, mask is stored in TCB.   TCB will be updated.  It applies
> to all threads.
> 
> > The interface assumes that the tag bits are uniform across pointer
> > types.  I think that's not true, at least from a historical perspective.
> 
> This is true for LAM and TBI.

on aarch64 TBI is always top byte (top 8bit).

there are separate data access and instruction access TBI, but
they are both on in linux userspace (there was an argument to
only use data access TBI so pointer authentication can use extra
8 bits for code pointers, however the TBI setting is slow to
context switch and we would need it to be per process if it's
an opt-in feature. it's not clear if anything would break by
disabling code address TBI, but for now we are stuck with the
original ABI).

when MTE is in use then 4bits (bit 56 .. 59) are used for memory
tagging, the other 4bits (top 4 bits) are technically still
available for application use. but i'm not yet sure if we want
to expose that. (e.g. in case of a fault on a tagged address
by default the tag is zeroed in siginfo.si_addr, but kept when
SA_EXPOSE_TAGBITS is set, except with an MTE tag check fault
the top 4 bits are never kept.)

originally in the linux syscall abi tag bytes must be 0, so in
libc calls the tag bytes must be 0 too: the architectural TBI
only works for memory accesses. but userspace can opt-in to a
tagged address abi that allows passing tagged addresses to the
kernel.
https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.rst

with the tagged address syscall abi tagged addresses are usable
in practice (e.g. for HWASAN, but also needed for MTE). this abi
is mostly backward compatible (i'm not sure if anything breaks
if it's unconditionally on, invalid syscalls may no longer fail).
https://www.kernel.org/doc/Documentation/arm64/tagged-address-abi.rst

we want the libc to decide early about the tagged syscall abi,
later there is no reliable way to do it for the entire process.
for this we may need to mark binaries that use tags (such
marking also tells us that the binary is not MTE compatible)
unfortunately HWASAN does not use any marking. (lack of marking
is an issue in other sanitizers too). currently the opt-in is
done based on a tunable that requests heap tagging.

> 
> > People complained that our protection key interfaces are too slow to be
> > useful.  Do we need to find a way to inline the tag/untag operations?
> >
> 
> The internal interface is inlined.  We can also inline the public interface
> if needed.  But set_tagged_address_mask isn't inlined at all.

i'm not sure how the set_tagged_address_mask api would work.