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

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* 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.

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.

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

Thanks,
Florian