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 6:49 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > 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.
>
> It's still unclear who owns the tag bits, and if the behavior is
> expected to be like the kernel (e.g., glibc masks all tag bits in
> dladdr so that they are ignored not just at the hardware level).

We don't have to decide now.  We will learn more with HWASAN.
With set_translated_address_mask, glibc can control/change how
tag bits should be used.  With kernel API, glibc is out of the picture.

> >> 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.
>
> Only if it is permitted to change the tag on subobjects, which I don't
> think is the case.  Otherwise overlaps necessarily have the same tag,
> and the existing pointer comparison works as expected.

It is not about overlap.  I am concerned about copy direction, like
if (dest > src), will it be a problem?

> >> 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.
>
> How does AArch64 solve this?  Different kernel API?

I don't think that AArch64 has addressed this issue at all.

-- 
H.J.