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:

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

Yet you were able to backport it.

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

Why can't you do this while we experiment with HWSAN?

>> 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?

It can make sure that the constructor runs as early as possible, so that
the appropriate system calls are made before any thread creation.

If the kernel interface does not provide coordination capabilities
between different LAM consumers within the same process (even a minimal
capability, like “has this been enabled yet?”), that sounds like a
serious drawback.

Thanks,
Florian