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

["H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>]

On Mon, Aug 23, 2021 at 2:28 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > 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).
>
> I think the fundamental concern is that we don't really know today how
> this API would be used.  Szabolcs has said that Arm doesn't need this
> API for HWSAN.  TBI has already other (incompatible) users, I think.
> (Although OpenJDK's ZGC garbage collector has moved off it.)
>
> My concern is that this interface essentialyl sets in stone a certain
> programming model for LAM, and we really don't know today if that's the
> right approach.

My current API has only set_translated_address_mask to enable LAM.
It doesn't specify/know how LAM is used.  I don't see there is an issue
here.

> I also expect that HWSAN needs to poke at glibc internals, like the
> other sanitizers, so I don't see why calling a kernel API behind glibc's
> back would be problematic.

The LAM enabled glibc should support all LAM usages.   memmove
needs to know the LAM bits to work properly.

> As a side effect of the libpthread merge, we freed DF_1_INITFIRST for
> other uses, so you should be able to work around initialization ordering
> issues, too.

The issue here is that LAM should only be enabled ONCE before main
and thread creation.  Neither DF_1_INITFIRST nor kernel API can properly
enforce it.

-- 
H.J.