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 Fri, Sep 3, 2021 at 2:12 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 08/23/2021 07:15, H.J. Lu via Libc-alpha wrote:
> > 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:
> > > >> 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.
>
> i expect the hwasan runtime to have an initializer that
> ensures that it runs once, early (e.g. the shadow map
> has to be set up very early too: before any instrumented
> user code may run)

There is nothing in glibc to enforce it.  LAM can be used by
HWASAN or others, including glibc itself.   We need to a way
to control it so that

1. LAM can be enabled properly.  For example, if LAM has
been enabled and used by HWASAN,  it can no longer be
used by glibc itself.
2. LAM can't be disabled arbitrarily.  We can't disable LAM
or change LAM_U57 to LAM_U48 when LAM is in use.

Otherwise, we may get crashes, surprises or security issues
when LAM is enabled/disabled at random places.

> is there a reason the lam setup cannot use this mechanism?

See above.

-- 
H.J.