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, Sep 6, 2021 at 1:52 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > 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.
>
> But these things are already happening with the software-based Address
> Sanitizer.  I doubt these long-standing issues will be fixed by LAM
> because they are not a hardware limitation, but the result of a lack of
> coordination between projects.

But I don't think we should add LAM to the list of the long-standing
issues.  Without an API, we can never safely use LAM in glibc at
all.

> Setting up LAM is just one more issue in a long list of things that can
> go wrong.  And if LAM does not have an ABI impact, it can be backported,
> which would be nice.

I backported it to glibc 2.33:

[hjl@gnu-cfl-2 tmp]$ ar -t /lib64/libc_nonshared.a
elf-init.oS
atexit.oS
at_quick_exit.oS
pthread_atfork.oS
set-translated-address-mask.oS
stack_chk_fail_local.oS
[hjl@gnu-cfl-2 tmp]$ ar -x /lib64/libc_nonshared.a  tagged-address.oS
set-translated-address-mask.oS
[hjl@gnu-cfl-2 tmp]$ nm set-translated-address-mask.oS
                 U errno
                 U _GLOBAL_OFFSET_TABLE_
                 U _rtld_global
0000000000000000 T set_translated_address_mask
                 U __stack_chk_fail_local
[hjl@gnu-cfl-2 tmp]

At least, the same source can compile with glibc 2.33 and the
binary linked against glibc 2.33 will run with newer glibc.

> Note that in glibc 2.34, we freed up DF_1_INITFIRST, so you could use
> that to set up things really early.

What do you have in mind for LAM with DF_1_INITFIRST?  How can it
address the LAM issues I have?

BTW, DF_1_INITFIRST doesn't help backport.

>
> Thanks,
> Florian
>

Thanks.

-- 
H.J.