[v5,1/1] <sys/tagged-address.h>: An API for tagged address

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

<sys/tagged-address.h> provides an API for tagged address manipulation
with restrictions:

1. All bits between 0 and N - 1, where N is the number of tagged address
bits, are used in address translation.
2. All pointers participating in a pointer arithmetic operation should have
the same tag if they point to the same memory object so that pointer
equality operation can be performed on tagged pointers.

/* Get the current address bits used in address translation.  */
extern unsigned int get_tagged_address_bits (void);

/* Get the current mask for address bits used in address translation.  */
extern uintptr_t get_tagged_address_mask (void);

/* Set the mask for address bits used in address translation.  Return 0
   on success.  Return -1 on error.  */
extern int set_tagged_address_mask (uintptr_t __mask);

/* Return the tagged address of __ADDR with the tag value __TAG.  */
extern void *tag_address (void *__addr, unsigned int __tag);

/* Return the untagged address of __ADDR.  */
extern void *untag_address (void *__addr);

/* TRUE if constant address BITS is a valid tagged address bits.  */
 #define TAGGED_ADDRESS_VALID_BITS(BITS)

/* A mask for constant address BITS used in address translation.  */
 #define TAGGED_ADDRESS_MASK(BITS)

1. set_tagged_address_mask should be called as early as possible.
2. set_tagged_address_mask shouldn't be allowed after main is called.
3. After set_tagged_address_mask is called, don't allow it to be called
again to change the tagged address mask.  Otherwise, the previously
tagged addresses may not work anymore.
---
 NEWS                                          |  2 +-
 bits/tagged-address-mask.h                    | 47 +++++++++++
 bits/tagged-address-valid-bits.h              | 28 +++++++
 csu/libc-start.c                              |  3 +
 elf/dl-support.c                              |  5 ++
 include/sys/tagged-address.h                  |  9 +++
 manual/Makefile                               |  3 +-
 manual/ctype.texi                             |  2 +-
 manual/memory.texi                            |  2 +-
 manual/tagged-address.texi                    | 80 +++++++++++++++++++
 misc/Makefile                                 | 35 ++++++--
 misc/Versions                                 |  7 ++
 misc/set-tagged-address-mask.c                | 41 ++++++++++
 misc/sys/tagged-address.h                     | 45 +++++++++++
 misc/tagged-address.c                         | 55 +++++++++++++
 misc/tst-tagged-address-1-static.c            |  1 +
 misc/tst-tagged-address-1.c                   | 53 ++++++++++++
 misc/tst-tagged-address-2-static.c            |  1 +
 misc/tst-tagged-address-2.c                   | 44 ++++++++++
 misc/tst-tagged-address-3-static.c            |  1 +
 misc/tst-tagged-address-3.c                   | 48 +++++++++++
 misc/tst-tagged-address-4-static.c            |  1 +
 misc/tst-tagged-address-4.c                   | 35 ++++++++
 misc/tst-tagged-address-5.c                   | 25 ++++++
 misc/tst-tagged-address-6.c                   | 34 ++++++++
 misc/tst-tagged-address-7.c                   | 40 ++++++++++
 misc/tst-tagged-address-mod-5.c               | 45 +++++++++++
 misc/tst-tagged-address-mod-6.c               | 34 ++++++++
 misc/tst-tagged-address-mod-7.c               | 34 ++++++++
 sysdeps/generic/inline-tagged-address.h       | 43 ++++++++++
 sysdeps/generic/ldsodefs.h                    |  4 +
 sysdeps/unix/sysv/linux/i386/libc.abilist     |  5 ++
 .../unix/sysv/linux/x86_64/64/libc.abilist    |  5 ++
 .../unix/sysv/linux/x86_64/x32/libc.abilist   |  5 ++
 34 files changed, 813 insertions(+), 9 deletions(-)
 create mode 100644 bits/tagged-address-mask.h
 create mode 100644 bits/tagged-address-valid-bits.h
 create mode 100644 include/sys/tagged-address.h
 create mode 100644 manual/tagged-address.texi
 create mode 100644 misc/set-tagged-address-mask.c
 create mode 100644 misc/sys/tagged-address.h
 create mode 100644 misc/tagged-address.c
 create mode 100644 misc/tst-tagged-address-1-static.c
 create mode 100644 misc/tst-tagged-address-1.c
 create mode 100644 misc/tst-tagged-address-2-static.c
 create mode 100644 misc/tst-tagged-address-2.c
 create mode 100644 misc/tst-tagged-address-3-static.c
 create mode 100644 misc/tst-tagged-address-3.c
 create mode 100644 misc/tst-tagged-address-4-static.c
 create mode 100644 misc/tst-tagged-address-4.c
 create mode 100644 misc/tst-tagged-address-5.c
 create mode 100644 misc/tst-tagged-address-6.c
 create mode 100644 misc/tst-tagged-address-7.c
 create mode 100644 misc/tst-tagged-address-mod-5.c
 create mode 100644 misc/tst-tagged-address-mod-6.c
 create mode 100644 misc/tst-tagged-address-mod-7.c
 create mode 100644 sysdeps/generic/inline-tagged-address.h
  

On Thu, 5 Aug 2021, H.J. Lu via Libc-alpha wrote:

> +#ifdef __GNUC__
> +# if defined __USE_ISOC11 || defined __USE_ISOCXX11
> +#  ifdef __USE_ISOCXX11
> +#   define TAGGED_ADDRESS_ASSERT static_assert
> +#  else
> +#   define TAGGED_ADDRESS_ASSERT _Static_assert
> +#  endif

These __USE_* conditionals say what library features to enable.  
__USE_ISOC11 doesn't imply that C11 language features are available; you 
can use -D_ISOC11_SOURCE with a GCC version too old to support 
_Static_assert.

However, you should be able to rely on _Static_assert when building as C 
(regardless of feature test macros or compiler versions) because of the 
definition in sys/cdefs.h.
  

On Thu, Aug 5, 2021 at 10:26 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 5 Aug 2021, H.J. Lu via Libc-alpha wrote:
>
> > +#ifdef __GNUC__
> > +# if defined __USE_ISOC11 || defined __USE_ISOCXX11
> > +#  ifdef __USE_ISOCXX11
> > +#   define TAGGED_ADDRESS_ASSERT static_assert
> > +#  else
> > +#   define TAGGED_ADDRESS_ASSERT _Static_assert
> > +#  endif
>
> These __USE_* conditionals say what library features to enable.
> __USE_ISOC11 doesn't imply that C11 language features are available; you
> can use -D_ISOC11_SOURCE with a GCC version too old to support
> _Static_assert.
>
> However, you should be able to rely on _Static_assert when building as C
> (regardless of feature test macros or compiler versions) because of the
> definition in sys/cdefs.h.

I can use _Static_assert directly for C.  How should I use static_assert
for C++?
  

On Thu, 5 Aug 2021, H.J. Lu via Libc-alpha wrote:

> I can use _Static_assert directly for C.  How should I use static_assert
> for C++?

Probably based on a test of the value of __cplusplus.
  

On Thu, Aug 5, 2021 at 10:54 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 5 Aug 2021, H.J. Lu via Libc-alpha wrote:
>
> > I can use _Static_assert directly for C.  How should I use static_assert
> > for C++?
>
> Probably based on a test of the value of __cplusplus.
>

Like

#ifdef __cplusplus
# if __cplusplus >= 201103L
#  define TAGGED_ADDRESS_ASSERT static_assert
# else
#  define TAGGED_ADDRESS_ASSERT(expr, msg)
# endif
#else
#  define TAGGED_ADDRESS_ASSERT _Static_assert
#endif

Thanks.
  

* H. J. Lu:

> diff --git a/manual/ctype.texi b/manual/ctype.texi
> index d0618c5c38..28af73ff0e 100644
> --- a/manual/ctype.texi
> +++ b/manual/ctype.texi
> @@ -1,4 +1,4 @@
> -@node Character Handling, String and Array Utilities, Memory, Top
> +@node Character Handling, String and Array Utilities, Tagged Address, Top
>  @c %MENU% Character testing and conversion functions
>  @chapter Character Handling

Allegedly, it should not be necessary to maintain the @node linkage
manually (if we remove it).

> diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi
> new file mode 100644
> index 0000000000..a3929a0eb7
> --- /dev/null
> +++ b/manual/tagged-address.texi
> @@ -0,0 +1,80 @@
> +@node Tagged Address, Character Handling, Memory, Top
> +@c %MENU% Tagged address functions and macros
> +@chapter Tagged Address
> +
> +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).

Current spelling is “Arm”, I think.

> +@Theglibc{} provides several functions and macros in the header file
> +@file{sys/tagged-address.h} to manipulate tagged address bits, which is
> +the number of the address bits used in address translation, with
> +restrictions:

Aren't the tagged address bits *not* used in address translation?

The Arm documentation

  <https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html>

implies that the tag bits are those that are ignored for address
translation purposes (e.g., “The syscall behaviour for a valid tagged
pointer is the same as for the corresponding untagged pointer.”).  This
manual change uses the reverse terminology: tagged address bits are
those that are used in address translation (including the untranslated
intra-page offset).

I find it more intuitive to refer to the ignored bits as “tagged address
bits”.

> +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> +@standards{GNU, sys/tagged-address.h}
> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> +Set the mask for address bits used in address translation to @var{mask}.
> +Only bits set in @var{mask} will be used in address translation.  The
> +return value is @code{0} on success and @code{-1} on failure.  This
> +function can be called only once before @code{main}.

Again the restriction around @code{main} is unclear.  If it's “before
allocating memory” or “before starting threads”, than we should say
that.

I still don't see a way how we can split tag address bits used by the
implementation (glibc, sanitizers) and the application.

For example, glibc could use a tag bit to indicate whether an allocation
is in a mmap-based allocation.  This way, we could use an out-of-line
object header (found via a hash table, for example), and utilize the
fact that mmap-based allocations are always page-aligned.  This would no
core malloc algorithm changes and should be an obvious improvement.
With more substantial changes, we could use another bit to encode that
an allocation is in a small objects region and does not have an
immediately preceding object header, either.  Introducing small object
regions is a much larger change, though.

Thanks,
Florian
  

The 08/12/2021 10:36, Florian Weimer wrote:
> * H. J. Lu:
> > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> > +@standards{GNU, sys/tagged-address.h}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > +Set the mask for address bits used in address translation to @var{mask}.
> > +Only bits set in @var{mask} will be used in address translation.  The
> > +return value is @code{0} on success and @code{-1} on failure.  This
> > +function can be called only once before @code{main}.
> 
> Again the restriction around @code{main} is unclear.  If it's “before
> allocating memory” or “before starting threads”, than we should say
> that.

it should be at least before thread creation on aarch64.

> I still don't see a way how we can split tag address bits used by the
> implementation (glibc, sanitizers) and the application.

an application may not be able to use tag bits at all:

+All pointers participating in a pointer arithmetic operation should have
+the same tag if they point to the same memory object so that pointer
+equality operation can be performed on tagged pointers.

if the implementation gives an untagged pointer to user code
which tags it then there are differently tagged pointers to
the same object: 0 tag and user tag. it is generally hard to
ensure that pointers don't escape and don't end up breaking
pointer cmp somewhere.

so one approach is to just disallow user tags, only sanitizer
and similar tools can tag (and i think hwasan can coordinate
with glibc via less formal api/abi that we can change later)

another approach is to allow user tags and user has to deal
with potential problems (requiring compiler barriers around
pointer tagging etc), in that case i think we have to reserve
bits for the implementation if we want to use that for malloc.
  

The 08/12/2021 13:01, Szabolcs Nagy via Libc-alpha wrote:
> The 08/12/2021 10:36, Florian Weimer wrote:
> > I still don't see a way how we can split tag address bits used by the
> > implementation (glibc, sanitizers) and the application.
...
> so one approach is to just disallow user tags, only sanitizer
> and similar tools can tag (and i think hwasan can coordinate
> with glibc via less formal api/abi that we can change later)

to expand on this: i think we should just focus on the hwasan
use-case. there may be other use-cases for tagged addresses,
but we need more experience before we can design a generic api.
hwasan can just poke at implementation internals and have
target specific logic for now.

allowing application code to use the tag bits can break c
semantics and compiler assumptions too easily.

and we should not require hwasan to use libc apis to work
with tagged addresses, that would slow it down.

so i think we don't need the tagged address representation
related apis. we may need something __hwasan_init can call
to set up os support. on aarch64 that's a prctl now, but a
libc api would allow us to disable hwasan from glibc (e.g.
if there are elf markings for incompatible dsos), i don't
know if that makes sense (does hwasan have a fall back if
there is no os support?).
  

On Tue, Aug 17, 2021 at 5:33 AM Szabolcs Nagy via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> The 08/12/2021 13:01, Szabolcs Nagy via Libc-alpha wrote:
> > The 08/12/2021 10:36, Florian Weimer wrote:
> > > I still don't see a way how we can split tag address bits used by the
> > > implementation (glibc, sanitizers) and the application.
> ...
> > so one approach is to just disallow user tags, only sanitizer
> > and similar tools can tag (and i think hwasan can coordinate
> > with glibc via less formal api/abi that we can change later)
>
> to expand on this: i think we should just focus on the hwasan
> use-case. there may be other use-cases for tagged addresses,
> but we need more experience before we can design a generic api.
> hwasan can just poke at implementation internals and have
> target specific logic for now.

Agreed.  My motivation is hwasan.

> allowing application code to use the tag bits can break c
> semantics and compiler assumptions too easily.
>
> and we should not require hwasan to use libc apis to work
> with tagged addresses, that would slow it down.

There is no reason why a libc API should be slow.   Currently,
LAM enabled libsanitizer/hwasan has

#include <sys/tagged-address.h>

bool lam_failed = set_tagged_address_mask (TAGGED_ADDRESS_MASK (57))

We only need this function to enable LAM in libsanitizer/hwasan
and inform glibc that LAM is enabled.  The rest of functions in
<sys/tagged-address.h> are used to make memmove and memmove
tests LAM compatible.  We can move them to internal header files.

> so i think we don't need the tagged address representation
> related apis. we may need something __hwasan_init can call
> to set up os support. on aarch64 that's a prctl now, but a
> libc api would allow us to disable hwasan from glibc (e.g.
> if there are elf markings for incompatible dsos), i don't

set_tagged_address_mask can be used to enable and disable
LAM/TBI.  memmove needs to know if LAM/TBI is enabled or not
to work correctly.

> know if that makes sense (does hwasan have a fall back if
> there is no os support?).
>

It is a hard error for hwasan if LAM/TBI isn't available.

Thanks.
  

The 08/17/2021 05:53, H.J. Lu via Libc-alpha wrote:
> On Tue, Aug 17, 2021 at 5:33 AM Szabolcs Nagy via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > The 08/12/2021 13:01, Szabolcs Nagy via Libc-alpha wrote:
> > > The 08/12/2021 10:36, Florian Weimer wrote:
> > > > I still don't see a way how we can split tag address bits used by the
> > > > implementation (glibc, sanitizers) and the application.
> > ...
> > > so one approach is to just disallow user tags, only sanitizer
> > > and similar tools can tag (and i think hwasan can coordinate
> > > with glibc via less formal api/abi that we can change later)
> >
> > to expand on this: i think we should just focus on the hwasan
> > use-case. there may be other use-cases for tagged addresses,
> > but we need more experience before we can design a generic api.
> > hwasan can just poke at implementation internals and have
> > target specific logic for now.
> 
> Agreed.  My motivation is hwasan.
> 
> > allowing application code to use the tag bits can break c
> > semantics and compiler assumptions too easily.
> >
> > and we should not require hwasan to use libc apis to work
> > with tagged addresses, that would slow it down.
> 
> There is no reason why a libc API should be slow.   Currently,
> LAM enabled libsanitizer/hwasan has
> 
> #include <sys/tagged-address.h>
> 
> bool lam_failed = set_tagged_address_mask (TAGGED_ADDRESS_MASK (57))
> 
> We only need this function to enable LAM in libsanitizer/hwasan
> and inform glibc that LAM is enabled.  The rest of functions in
> <sys/tagged-address.h> are used to make memmove and memmove
> tests LAM compatible.  We can move them to internal header files.

ok.

libc internal api is a different story, i thought you
expect hwasan to use tag_address, get_tagged_address_mask
etc and that would affect hwasan code gen.

if that's not the case then i don't think these apis should
be exposed.

> > so i think we don't need the tagged address representation
> > related apis. we may need something __hwasan_init can call
> > to set up os support. on aarch64 that's a prctl now, but a
> > libc api would allow us to disable hwasan from glibc (e.g.
> > if there are elf markings for incompatible dsos), i don't
> 
> set_tagged_address_mask can be used to enable and disable
> LAM/TBI.  memmove needs to know if LAM/TBI is enabled or not
> to work correctly.

i'm not convinced memmove needs to know.

if hwasan tags memory more fine grained than what is
passed to memmove as single object then there can be
issues in user code too with pointer diff calculations
within that object.

> > know if that makes sense (does hwasan have a fall back if
> > there is no os support?).
> >
> 
> It is a hard error for hwasan if LAM/TBI isn't available.
> 
> Thanks.

i see.
  

On Tue, Aug 17, 2021 at 8:00 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 08/17/2021 05:53, H.J. Lu via Libc-alpha wrote:
> > On Tue, Aug 17, 2021 at 5:33 AM Szabolcs Nagy via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> > >
> > > The 08/12/2021 13:01, Szabolcs Nagy via Libc-alpha wrote:
> > > > The 08/12/2021 10:36, Florian Weimer wrote:
> > > > > I still don't see a way how we can split tag address bits used by the
> > > > > implementation (glibc, sanitizers) and the application.
> > > ...
> > > > so one approach is to just disallow user tags, only sanitizer
> > > > and similar tools can tag (and i think hwasan can coordinate
> > > > with glibc via less formal api/abi that we can change later)
> > >
> > > to expand on this: i think we should just focus on the hwasan
> > > use-case. there may be other use-cases for tagged addresses,
> > > but we need more experience before we can design a generic api.
> > > hwasan can just poke at implementation internals and have
> > > target specific logic for now.
> >
> > Agreed.  My motivation is hwasan.
> >
> > > allowing application code to use the tag bits can break c
> > > semantics and compiler assumptions too easily.
> > >
> > > and we should not require hwasan to use libc apis to work
> > > with tagged addresses, that would slow it down.
> >
> > There is no reason why a libc API should be slow.   Currently,
> > LAM enabled libsanitizer/hwasan has
> >
> > #include <sys/tagged-address.h>
> >
> > bool lam_failed = set_tagged_address_mask (TAGGED_ADDRESS_MASK (57))
> >
> > We only need this function to enable LAM in libsanitizer/hwasan
> > and inform glibc that LAM is enabled.  The rest of functions in
> > <sys/tagged-address.h> are used to make memmove and memmove
> > tests LAM compatible.  We can move them to internal header files.
>
> ok.
>
> libc internal api is a different story, i thought you
> expect hwasan to use tag_address, get_tagged_address_mask
> etc and that would affect hwasan code gen.

They are not used in the current implementation of LAM-enabled hwasan.

> if that's not the case then i don't think these apis should
> be exposed.
>
> > > so i think we don't need the tagged address representation
> > > related apis. we may need something __hwasan_init can call
> > > to set up os support. on aarch64 that's a prctl now, but a
> > > libc api would allow us to disable hwasan from glibc (e.g.
> > > if there are elf markings for incompatible dsos), i don't
> >
> > set_tagged_address_mask can be used to enable and disable
> > LAM/TBI.  memmove needs to know if LAM/TBI is enabled or not
> > to work correctly.
>
> i'm not convinced memmove needs to know.

memmove may not need to know LAM bits for hwasn.  But memmove
needs to know if LAM is enabled in general.

> if hwasan tags memory more fine grained than what is
> passed to memmove as single object then there can be
> issues in user code too with pointer diff calculations
> within that object.
>
> > > know if that makes sense (does hwasan have a fall back if
> > > there is no os support?).
> > >
> >
> > It is a hard error for hwasan if LAM/TBI isn't available.
> >
> > Thanks.
>
> i see.



--
H.J.
  

On Thu, Aug 12, 2021 at 5:01 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 08/12/2021 10:36, Florian Weimer wrote:
> > * H. J. Lu:
> > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> > > +@standards{GNU, sys/tagged-address.h}
> > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > > +Set the mask for address bits used in address translation to @var{mask}.
> > > +Only bits set in @var{mask} will be used in address translation.  The
> > > +return value is @code{0} on success and @code{-1} on failure.  This
> > > +function can be called only once before @code{main}.
> >
> > Again the restriction around @code{main} is unclear.  If it's “before
> > allocating memory” or “before starting threads”, than we should say
> > that.
>
> it should be at least before thread creation on aarch64.

Before main is before thread creation and before main is safer
than before thread creation.

> > I still don't see a way how we can split tag address bits used by the
> > implementation (glibc, sanitizers) and the application.
>
> an application may not be able to use tag bits at all:
>
> +All pointers participating in a pointer arithmetic operation should have
> +the same tag if they point to the same memory object so that pointer
> +equality operation can be performed on tagged pointers.
>
> if the implementation gives an untagged pointer to user code
> which tags it then there are differently tagged pointers to
> the same object: 0 tag and user tag. it is generally hard to
> ensure that pointers don't escape and don't end up breaking
> pointer cmp somewhere.
>
> so one approach is to just disallow user tags, only sanitizer
> and similar tools can tag (and i think hwasan can coordinate
> with glibc via less formal api/abi that we can change later)
>
> another approach is to allow user tags and user has to deal
> with potential problems (requiring compiler barriers around
> pointer tagging etc), in that case i think we have to reserve
> bits for the implementation if we want to use that for malloc.

Tag usage must be exclusive for malloc or HWASAN.   malloc
usage must be checked at run-time for

1. Is tag enabled? And
2. Is tag used for another purpose?

If tag isn't enabled or used for another purpose, malloc should
avoid using tag.   This API can inform glibc that an user code
is requesting tag usage.
  

* H. J. Lu:

> On Thu, Aug 12, 2021 at 5:01 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>
>> The 08/12/2021 10:36, Florian Weimer wrote:
>> > * H. J. Lu:
>> > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
>> > > +@standards{GNU, sys/tagged-address.h}
>> > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
>> > > +Set the mask for address bits used in address translation to @var{mask}.
>> > > +Only bits set in @var{mask} will be used in address translation.  The
>> > > +return value is @code{0} on success and @code{-1} on failure.  This
>> > > +function can be called only once before @code{main}.
>> >
>> > Again the restriction around @code{main} is unclear.  If it's “before
>> > allocating memory” or “before starting threads”, than we should say
>> > that.
>>
>> it should be at least before thread creation on aarch64.
>
> Before main is before thread creation and before main is safer
> than before thread creation.

You can create threads from ELF constructors, and those run before main.
(Although this tends to run into deadlocks in our implementation.)

Thanks,
Florian
  

On Fri, Aug 20, 2021 at 9:25 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Thu, Aug 12, 2021 at 5:01 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >>
> >> The 08/12/2021 10:36, Florian Weimer wrote:
> >> > * H. J. Lu:
> >> > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> >> > > +@standards{GNU, sys/tagged-address.h}
> >> > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> >> > > +Set the mask for address bits used in address translation to @var{mask}.
> >> > > +Only bits set in @var{mask} will be used in address translation.  The
> >> > > +return value is @code{0} on success and @code{-1} on failure.  This
> >> > > +function can be called only once before @code{main}.
> >> >
> >> > Again the restriction around @code{main} is unclear.  If it's “before
> >> > allocating memory” or “before starting threads”, than we should say
> >> > that.
> >>
> >> it should be at least before thread creation on aarch64.
> >
> > Before main is before thread creation and before main is safer
> > than before thread creation.
>
> You can create threads from ELF constructors, and those run before main.
> (Although this tends to run into deadlocks in our implementation.)

I will change the wording to before man AND thread creation.
  

On Thu, Aug 12, 2021 at 1:36 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > diff --git a/manual/ctype.texi b/manual/ctype.texi
> > index d0618c5c38..28af73ff0e 100644
> > --- a/manual/ctype.texi
> > +++ b/manual/ctype.texi
> > @@ -1,4 +1,4 @@
> > -@node Character Handling, String and Array Utilities, Memory, Top
> > +@node Character Handling, String and Array Utilities, Tagged Address, Top
> >  @c %MENU% Character testing and conversion functions
> >  @chapter Character Handling
>
> Allegedly, it should not be necessary to maintain the @node linkage
> manually (if we remove it).

Since @node isn't removed, I guess I have to keep this change.

> > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi
> > new file mode 100644
> > index 0000000000..a3929a0eb7
> > --- /dev/null
> > +++ b/manual/tagged-address.texi
> > @@ -0,0 +1,80 @@
> > +@node Tagged Address, Character Handling, Memory, Top
> > +@c %MENU% Tagged address functions and macros
> > +@chapter Tagged Address
> > +
> > +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).
>
> Current spelling is “Arm”, I think.

There are

contrib.texi:Philip Blundell for the ports to Linux/ARM
contrib.texi:(@code{arm-@var{ANYTHING}-linuxaout}) and ARM standalone
contrib.texi:Richard Earnshaw for continued support and fixes to the various ARM
contrib.texi:his maintainership of the ARM and MIPS architectures and the math
contrib.texi:encryption support for ARM and various fixes.
creature.texi:architectures (i686, ARM), this is planned to change and
applications

and

contrib.texi:Ulrich Weigand for various fixes to the PowerPC64 and Arm ports.

I will keep ARM.

> > +@Theglibc{} provides several functions and macros in the header file
> > +@file{sys/tagged-address.h} to manipulate tagged address bits, which is
> > +the number of the address bits used in address translation, with
> > +restrictions:
>
> Aren't the tagged address bits *not* used in address translation?
>
> The Arm documentation
>
>   <https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html>
>
> implies that the tag bits are those that are ignored for address
> translation purposes (e.g., “The syscall behaviour for a valid tagged
> pointer is the same as for the corresponding untagged pointer.”).  This
> manual change uses the reverse terminology: tagged address bits are
> those that are used in address translation (including the untranslated
> intra-page offset).
>
> I find it more intuitive to refer to the ignored bits as “tagged address
> bits”.

I will rename it to set_translated_address_mask.

> > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> > +@standards{GNU, sys/tagged-address.h}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > +Set the mask for address bits used in address translation to @var{mask}.
> > +Only bits set in @var{mask} will be used in address translation.  The
> > +return value is @code{0} on success and @code{-1} on failure.  This
> > +function can be called only once before @code{main}.
>
> Again the restriction around @code{main} is unclear.  If it's “before
> allocating memory” or “before starting threads”, than we should say
> that.

I will change it to

This function can be called only once before @code{main} and thread creation.

> I still don't see a way how we can split tag address bits used by the
> implementation (glibc, sanitizers) and the application.
>
> For example, glibc could use a tag bit to indicate whether an allocation
> is in a mmap-based allocation.  This way, we could use an out-of-line
> object header (found via a hash table, for example), and utilize the
> fact that mmap-based allocations are always page-aligned.  This would no
> core malloc algorithm changes and should be an obvious improvement.
> With more substantial changes, we could use another bit to encode that
> an allocation is in a small objects region and does not have an
> immediately preceding object header, either.  Introducing small object
> regions is a much larger change, though.
>

Tag usage should be exclusive to glibc.  set_translated_address_mask
tells glibc that tag will be used for another purpose.

Thanks.
  

On Fri, Aug 20, 2021 at 4:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:

> On Thu, Aug 12, 2021 at 1:36 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * H. J. Lu:
> >
> > > diff --git a/manual/ctype.texi b/manual/ctype.texi
> > > index d0618c5c38..28af73ff0e 100644
> > > --- a/manual/ctype.texi
> > > +++ b/manual/ctype.texi
> > > @@ -1,4 +1,4 @@
> > > -@node Character Handling, String and Array Utilities, Memory, Top
> > > +@node Character Handling, String and Array Utilities, Tagged Address,
> Top
> > >  @c %MENU% Character testing and conversion functions
> > >  @chapter Character Handling
> >
> > Allegedly, it should not be necessary to maintain the @node linkage
> > manually (if we remove it).
>
> Since @node isn't removed, I guess I have to keep this change.
>
> > > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi
> > > new file mode 100644
> > > index 0000000000..a3929a0eb7
> > > --- /dev/null
> > > +++ b/manual/tagged-address.texi
> > > @@ -0,0 +1,80 @@
> > > +@node Tagged Address, Character Handling, Memory, Top
> > > +@c %MENU% Tagged address functions and macros
> > > +@chapter Tagged Address
> > > +
> > > +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).
> >
> > Current spelling is “Arm”, I think.
>
> There are
>
> contrib.texi:Philip Blundell for the ports to Linux/ARM
> contrib.texi:(@code{arm-@var{ANYTHING}-linuxaout}) and ARM standalone
> contrib.texi:Richard Earnshaw for continued support and fixes to the
> various ARM
> contrib.texi:his maintainership of the ARM and MIPS architectures and the
> math
> contrib.texi:encryption support for ARM and various fixes.
> creature.texi:architectures (i686, ARM), this is planned to change and
> applications
>
> and
>
> contrib.texi:Ulrich Weigand for various fixes to the PowerPC64 and Arm
> ports.
>
> I will keep ARM.
>
> > > +@Theglibc{} provides several functions and macros in the header file
> > > +@file{sys/tagged-address.h} to manipulate tagged address bits, which
> is
> > > +the number of the address bits used in address translation, with
> > > +restrictions:
> >
> > Aren't the tagged address bits *not* used in address translation?
> >
> > The Arm documentation
> >
> >   <https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html>
> >
> > implies that the tag bits are those that are ignored for address
> > translation purposes (e.g., “The syscall behaviour for a valid tagged
> > pointer is the same as for the corresponding untagged pointer.”).  This
> > manual change uses the reverse terminology: tagged address bits are
> > those that are used in address translation (including the untranslated
> > intra-page offset).
> >
> > I find it more intuitive to refer to the ignored bits as “tagged address
> > bits”.
>
> I will rename it to set_translated_address_mask.
>
Existing name set_tagged_address_mask may not be intuitive but it looks
more clear to me than the proposed new name(set_translated_address_mask).
For the proposed new name, it is not clear which particular portion of
address will be masked.
How about set_address_tagbit_mask?

>
> > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> > > +@standards{GNU, sys/tagged-address.h}
> > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > > +Set the mask for address bits used in address translation to
> @var{mask}.
> > > +Only bits set in @var{mask} will be used in address translation.  The
> > > +return value is @code{0} on success and @code{-1} on failure.  This
> > > +function can be called only once before @code{main}.
> >
> > Again the restriction around @code{main} is unclear.  If it's “before
> > allocating memory” or “before starting threads”, than we should say
> > that.
>
> I will change it to
>
> This function can be called only once before @code{main} and thread
> creation.
>
> > I still don't see a way how we can split tag address bits used by the
> > implementation (glibc, sanitizers) and the application.
> >
> > For example, glibc could use a tag bit to indicate whether an allocation
> > is in a mmap-based allocation.  This way, we could use an out-of-line
> > object header (found via a hash table, for example), and utilize the
> > fact that mmap-based allocations are always page-aligned.  This would no
> > core malloc algorithm changes and should be an obvious improvement.
> > With more substantial changes, we could use another bit to encode that
> > an allocation is in a small objects region and does not have an
> > immediately preceding object header, either.  Introducing small object
> > regions is a much larger change, though.
> >
>
> Tag usage should be exclusive to glibc.  set_translated_address_mask
> tells glibc that tag will be used for another purpose.
>
> Thanks.
>
> --
> H.J.
>
  

On Sat, Aug 21, 2021 at 9:10 AM Sunil Pandey <skpgkp2@gmail.com> wrote:
>
>
>
> On Fri, Aug 20, 2021 at 4:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Thu, Aug 12, 2021 at 1:36 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >
>> > * H. J. Lu:
>> >
>> > > diff --git a/manual/ctype.texi b/manual/ctype.texi
>> > > index d0618c5c38..28af73ff0e 100644
>> > > --- a/manual/ctype.texi
>> > > +++ b/manual/ctype.texi
>> > > @@ -1,4 +1,4 @@
>> > > -@node Character Handling, String and Array Utilities, Memory, Top
>> > > +@node Character Handling, String and Array Utilities, Tagged Address, Top
>> > >  @c %MENU% Character testing and conversion functions
>> > >  @chapter Character Handling
>> >
>> > Allegedly, it should not be necessary to maintain the @node linkage
>> > manually (if we remove it).
>>
>> Since @node isn't removed, I guess I have to keep this change.
>>
>> > > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi
>> > > new file mode 100644
>> > > index 0000000000..a3929a0eb7
>> > > --- /dev/null
>> > > +++ b/manual/tagged-address.texi
>> > > @@ -0,0 +1,80 @@
>> > > +@node Tagged Address, Character Handling, Memory, Top
>> > > +@c %MENU% Tagged address functions and macros
>> > > +@chapter Tagged Address
>> > > +
>> > > +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).
>> >
>> > Current spelling is “Arm”, I think.
>>
>> There are
>>
>> contrib.texi:Philip Blundell for the ports to Linux/ARM
>> contrib.texi:(@code{arm-@var{ANYTHING}-linuxaout}) and ARM standalone
>> contrib.texi:Richard Earnshaw for continued support and fixes to the various ARM
>> contrib.texi:his maintainership of the ARM and MIPS architectures and the math
>> contrib.texi:encryption support for ARM and various fixes.
>> creature.texi:architectures (i686, ARM), this is planned to change and
>> applications
>>
>> and
>>
>> contrib.texi:Ulrich Weigand for various fixes to the PowerPC64 and Arm ports.
>>
>> I will keep ARM.
>>
>> > > +@Theglibc{} provides several functions and macros in the header file
>> > > +@file{sys/tagged-address.h} to manipulate tagged address bits, which is
>> > > +the number of the address bits used in address translation, with
>> > > +restrictions:
>> >
>> > Aren't the tagged address bits *not* used in address translation?
>> >
>> > The Arm documentation
>> >
>> >   <https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html>
>> >
>> > implies that the tag bits are those that are ignored for address
>> > translation purposes (e.g., “The syscall behaviour for a valid tagged
>> > pointer is the same as for the corresponding untagged pointer.”).  This
>> > manual change uses the reverse terminology: tagged address bits are
>> > those that are used in address translation (including the untranslated
>> > intra-page offset).
>> >
>> > I find it more intuitive to refer to the ignored bits as “tagged address
>> > bits”.
>>
>> I will rename it to set_translated_address_mask.
>
> Existing name set_tagged_address_mask may not be intuitive but it looks more clear to me than the proposed new name(set_translated_address_mask). For the proposed new name, it is not clear which particular portion of address will be masked.
> How about set_address_tagbit_mask?

Can you give it an example of how set_address_tagbit_mask should
be used?

>>
>>
>> > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
>> > > +@standards{GNU, sys/tagged-address.h}
>> > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
>> > > +Set the mask for address bits used in address translation to @var{mask}.
>> > > +Only bits set in @var{mask} will be used in address translation.  The
>> > > +return value is @code{0} on success and @code{-1} on failure.  This
>> > > +function can be called only once before @code{main}.
>> >
>> > Again the restriction around @code{main} is unclear.  If it's “before
>> > allocating memory” or “before starting threads”, than we should say
>> > that.
>>
>> I will change it to
>>
>> This function can be called only once before @code{main} and thread creation.
>>
>> > I still don't see a way how we can split tag address bits used by the
>> > implementation (glibc, sanitizers) and the application.
>> >
>> > For example, glibc could use a tag bit to indicate whether an allocation
>> > is in a mmap-based allocation.  This way, we could use an out-of-line
>> > object header (found via a hash table, for example), and utilize the
>> > fact that mmap-based allocations are always page-aligned.  This would no
>> > core malloc algorithm changes and should be an obvious improvement.
>> > With more substantial changes, we could use another bit to encode that
>> > an allocation is in a small objects region and does not have an
>> > immediately preceding object header, either.  Introducing small object
>> > regions is a much larger change, though.
>> >
>>
>> Tag usage should be exclusive to glibc.  set_translated_address_mask
>> tells glibc that tag will be used for another purpose.
>>
>> Thanks.
>>
>> --
>> H.J.
  

On Sat, Aug 21, 2021 at 9:38 AM H.J. Lu <hjl.tools@gmail.com> wrote:

> On Sat, Aug 21, 2021 at 9:10 AM Sunil Pandey <skpgkp2@gmail.com> wrote:
> >
> >
> >
> > On Fri, Aug 20, 2021 at 4:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> On Thu, Aug 12, 2021 at 1:36 AM Florian Weimer <fweimer@redhat.com>
> wrote:
> >> >
> >> > * H. J. Lu:
> >> >
> >> > > diff --git a/manual/ctype.texi b/manual/ctype.texi
> >> > > index d0618c5c38..28af73ff0e 100644
> >> > > --- a/manual/ctype.texi
> >> > > +++ b/manual/ctype.texi
> >> > > @@ -1,4 +1,4 @@
> >> > > -@node Character Handling, String and Array Utilities, Memory, Top
> >> > > +@node Character Handling, String and Array Utilities, Tagged
> Address, Top
> >> > >  @c %MENU% Character testing and conversion functions
> >> > >  @chapter Character Handling
> >> >
> >> > Allegedly, it should not be necessary to maintain the @node linkage
> >> > manually (if we remove it).
> >>
> >> Since @node isn't removed, I guess I have to keep this change.
> >>
> >> > > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi
> >> > > new file mode 100644
> >> > > index 0000000000..a3929a0eb7
> >> > > --- /dev/null
> >> > > +++ b/manual/tagged-address.texi
> >> > > @@ -0,0 +1,80 @@
> >> > > +@node Tagged Address, Character Handling, Memory, Top
> >> > > +@c %MENU% Tagged address functions and macros
> >> > > +@chapter Tagged Address
> >> > > +
> >> > > +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).
> >> >
> >> > Current spelling is “Arm”, I think.
> >>
> >> There are
> >>
> >> contrib.texi:Philip Blundell for the ports to Linux/ARM
> >> contrib.texi:(@code{arm-@var{ANYTHING}-linuxaout}) and ARM standalone
> >> contrib.texi:Richard Earnshaw for continued support and fixes to the
> various ARM
> >> contrib.texi:his maintainership of the ARM and MIPS architectures and
> the math
> >> contrib.texi:encryption support for ARM and various fixes.
> >> creature.texi:architectures (i686, ARM), this is planned to change and
> >> applications
> >>
> >> and
> >>
> >> contrib.texi:Ulrich Weigand for various fixes to the PowerPC64 and Arm
> ports.
> >>
> >> I will keep ARM.
> >>
> >> > > +@Theglibc{} provides several functions and macros in the header
> file
> >> > > +@file{sys/tagged-address.h} to manipulate tagged address bits,
> which is
> >> > > +the number of the address bits used in address translation, with
> >> > > +restrictions:
> >> >
> >> > Aren't the tagged address bits *not* used in address translation?
> >> >
> >> > The Arm documentation
> >> >
> >> >   <
> https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html>
> >> >
> >> > implies that the tag bits are those that are ignored for address
> >> > translation purposes (e.g., “The syscall behaviour for a valid tagged
> >> > pointer is the same as for the corresponding untagged pointer.”).
> This
> >> > manual change uses the reverse terminology: tagged address bits are
> >> > those that are used in address translation (including the untranslated
> >> > intra-page offset).
> >> >
> >> > I find it more intuitive to refer to the ignored bits as “tagged
> address
> >> > bits”.
> >>
> >> I will rename it to set_translated_address_mask.
> >
> > Existing name set_tagged_address_mask may not be intuitive but it looks
> more clear to me than the proposed new name(set_translated_address_mask).
> For the proposed new name, it is not clear which particular portion of
> address will be masked.
> > How about set_address_tagbit_mask?
>
> Can you give it an example of how set_address_tagbit_mask should
> be used?
>
I looked at the code again, for the set_tagged_address_mask, it will set
machine to ignore the upper bits depending on parameters, independent of
how upper bits will actually be used by the application. You are correct,
api name shouldn't have tagged in it.

>
> >>
> >>
> >> > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> >> > > +@standards{GNU, sys/tagged-address.h}
> >> > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> >> > > +Set the mask for address bits used in address translation to
> @var{mask}.
> >> > > +Only bits set in @var{mask} will be used in address translation.
> The
> >> > > +return value is @code{0} on success and @code{-1} on failure.  This
> >> > > +function can be called only once before @code{main}.
> >> >
> >> > Again the restriction around @code{main} is unclear.  If it's “before
> >> > allocating memory” or “before starting threads”, than we should say
> >> > that.
> >>
> >> I will change it to
> >>
> >> This function can be called only once before @code{main} and thread
> creation.
> >>
> >> > I still don't see a way how we can split tag address bits used by the
> >> > implementation (glibc, sanitizers) and the application.
> >> >
> >> > For example, glibc could use a tag bit to indicate whether an
> allocation
> >> > is in a mmap-based allocation.  This way, we could use an out-of-line
> >> > object header (found via a hash table, for example), and utilize the
> >> > fact that mmap-based allocations are always page-aligned.  This would
> no
> >> > core malloc algorithm changes and should be an obvious improvement.
> >> > With more substantial changes, we could use another bit to encode that
> >> > an allocation is in a small objects region and does not have an
> >> > immediately preceding object header, either.  Introducing small object
> >> > regions is a much larger change, though.
> >> >
> >>
> >> Tag usage should be exclusive to glibc.  set_translated_address_mask
> >> tells glibc that tag will be used for another purpose.
> >>
> >> Thanks.
> >>
> >> --
> >> H.J.
>
>
>
> --
> H.J.
>