Re: [PATCH v4 1/2] <sys/tagged-address.h>: An API for tagged address

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

The 04/21/2021 16:21, H.J. Lu via Libc-alpha wrote:
> On Tue, Apr 20, 2021 at 11:36 PM Florian Weimer <fweimer@redhat.com> wrote:
> > * H. J. Lu:
> > > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi
> > > new file mode 100644
> > > index 0000000000..ce10f7e752
> > > --- /dev/null
> > > +++ b/manual/tagged-address.texi
> > > @@ -0,0 +1,59 @@
> > > +@node Tagged Address, Character Handling, Memory, Top
> > > +@c %MENU% Tagged address functions and macros
> > > +@chapter Tagged Address
> > > +
> > > +By default, the number of the address bits used in address translation
> > > +is the number of address bits.  But it can be changed by ARM Top-byte
> > > +Ignore (TBI) or Intel Linear Address Masking (LAM).
> > > +
> > > +@Theglibc{} provides several functions and macros in the header file
> > > +@file{sys/tagged-address.h} to manipulate tagged address bits, which is
> > > +the number of the address bits used in address translation.
> > > +@pindex sys/tagged-address.h
> >
> > I don't under stand the “which is the number of address bits” part.
> 
> For tagged addresses, not all bits are used in address translation.
> For TBI, only the lower 48 bits are used in address translation.
> For LAM, it can be either the lower 48 bits or 57 bits.
> 
> > This section needs to describe under which circumstances it is valid to
> > alter the tag bits in pointers returned from glibc functions (including
> 
> Tagged address is enabled only when get_tagged_address_mask () != -1.
> 


> > system call wrappers).  I think at least historically, the kernel
> > required masking tag bits in user space for TBI.
> 
> I believe this has been fixed in the recent kernel.

on aarch64 we need

prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0);

while single threaded to enable the tagged address syscall abi, see
https://www.kernel.org/doc/html/latest/arm64/tagged-pointers.html

we do this for heap tagging because that depends on it, but we
don't enable it otherwise because previously invalid addresses
now may succeed instead of EFAULT/EINVAL in syscalls.

i think glibc can just enable it by default (always run processes
with tagged address syscall abi), i don't think that would cause
regressions other than different errno in some odd mmap etc usage.
(i think one glibc test fails along this line with heap tagging
enabled, if that's considered risky then we can do some per process
opt-in, but a libc call is problematic as it can be too late)