diff mbox series

[v3,1/8] config: Allow memory tagging to be enabled when configuring glibc

Message ID 20201123154236.25809-2-rearnsha@arm.com
State Superseded
Headers
Series Memory tagging support |

Commit Message

Richard Earnshaw Nov. 23, 2020, 3:42 p.m. UTC 
  This patch adds the configuration machinery to allow memory tagging to be
enabled from the command line via the configure option --enable-memory-tagging.

The current default is off, though in time we may change that once the API
is more stable.
---
 INSTALL             | 14 ++++++++++++++
 config.h.in         |  3 +++
 config.make.in      |  2 ++
 configure           | 17 +++++++++++++++++
 configure.ac        | 10 ++++++++++
 manual/install.texi | 13 +++++++++++++
 6 files changed, 59 insertions(+)

Comments

Siddhesh Poyarekar Nov. 25, 2020, 3:05 p.m. UTC | #1 
On 11/23/20 9:12 PM, Richard Earnshaw via Libc-alpha wrote:
> 
> This patch adds the configuration machinery to allow memory tagging to be
> enabled from the command line via the configure option --enable-memory-tagging.
> 
> The current default is off, though in time we may change that once the API
> is more stable.
> ---
>   INSTALL             | 14 ++++++++++++++
>   config.h.in         |  3 +++
>   config.make.in      |  2 ++
>   configure           | 17 +++++++++++++++++
>   configure.ac        | 10 ++++++++++
>   manual/install.texi | 13 +++++++++++++
>   6 files changed, 59 insertions(+)
> 
> diff --git a/INSTALL b/INSTALL
> index 2b00f80df5..f2476df6c0 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -142,6 +142,20 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
>       non-CET processors.  '--enable-cet' has been tested for i686,
>       x86_64 and x32 on CET processors.
>  
> +'--enable-memory-tagging'
> +     Enable memory tagging support on architectures that support it.
> +     When the GNU C Library is built with this option then the resulting
> +     library will be able to control the use of tagged memory when
> +     hardware support is present by use of the tunable
> +     'glibc.memtag.enable'.  This includes the generation of tagged
> +     memory when using the 'malloc' APIs.
> +
> +     At present only AArch64 platforms with MTE provide this
> +     functionality, although the library will still operate (without
> +     memory tagging) on older versions of the architecture.
> +
> +     The default is to disable support for memory tagging.
> +
>  '--disable-profile'
>       Don't build libraries with profiling information.  You may want to
>       use this option if you don't plan to do profiling.
> diff --git a/config.h.in b/config.h.in
> index b823c8e080..2f4c626c19 100644
> --- a/config.h.in
> +++ b/config.h.in
> @@ -160,6 +160,9 @@
>  /* Define if __stack_chk_guard canary should be randomized at program startup.  */
>  #undef ENABLE_STACKGUARD_RANDOMIZE
>  
> +/* Define if memory tagging support should be enabled.  */
> +#undef _LIBC_MTAG
> +
>  /* Package description.  */
>  #undef PKGVERSION
>  
> diff --git a/config.make.in b/config.make.in
> index 1ac9417245..7ae27564fd 100644
> --- a/config.make.in
> +++ b/config.make.in
> @@ -84,6 +84,8 @@ mach-interface-list = @mach_interface_list@
>  
>  experimental-malloc = @experimental_malloc@
>  
> +memory-tagging = @memory_tagging@
> +
>  nss-crypt = @libc_cv_nss_crypt@
>  static-nss-crypt = @libc_cv_static_nss_crypt@
>  
> diff --git a/configure b/configure
> index 4795e721e5..d22654739f 100755
> --- a/configure
> +++ b/configure
> @@ -676,6 +676,7 @@ build_nscd
>  libc_cv_static_nss_crypt
>  libc_cv_nss_crypt
>  build_crypt
> +memory_tagging
>  experimental_malloc
>  enable_werror
>  all_warnings
> @@ -781,6 +782,7 @@ enable_all_warnings
>  enable_werror
>  enable_multi_arch
>  enable_experimental_malloc
> +enable_memory_tagging
>  enable_crypt
>  enable_nss_crypt
>  enable_systemtap
> @@ -1450,6 +1452,8 @@ Optional Features:
>                            architectures
>    --disable-experimental-malloc
>                            disable experimental malloc features
> +  --enable-memory-tagging enable memory tagging if supported by the
> +                          architecture [default=no]

I wonder if that phrasing implies that the flag is disabled if memory 
tagging is not supported by the architecture.  The description in 
INSTALL (Enable memory tagging support on architectures that support it) 
seems a bit more precise.

Siddhesh
Richard Earnshaw (lists) Nov. 25, 2020, 3:09 p.m. UTC | #2 
On 25/11/2020 15:05, Siddhesh Poyarekar wrote:
> On 11/23/20 9:12 PM, Richard Earnshaw via Libc-alpha wrote:
>>
>> This patch adds the configuration machinery to allow memory tagging to be
>> enabled from the command line via the configure option
>> --enable-memory-tagging.
>>
>> The current default is off, though in time we may change that once the
>> API
>> is more stable.
>> ---
>>   INSTALL             | 14 ++++++++++++++
>>   config.h.in         |  3 +++
>>   config.make.in      |  2 ++
>>   configure           | 17 +++++++++++++++++
>>   configure.ac        | 10 ++++++++++
>>   manual/install.texi | 13 +++++++++++++
>>   6 files changed, 59 insertions(+)
>>
>> diff --git a/INSTALL b/INSTALL
>> index 2b00f80df5..f2476df6c0 100644
>> --- a/INSTALL
>> +++ b/INSTALL
>> @@ -142,6 +142,20 @@ if 'CFLAGS' is specified it must enable
>> optimization.  For example:
>>       non-CET processors.  '--enable-cet' has been tested for i686,
>>       x86_64 and x32 on CET processors.
>>  
>> +'--enable-memory-tagging'
>> +     Enable memory tagging support on architectures that support it.
>> +     When the GNU C Library is built with this option then the resulting
>> +     library will be able to control the use of tagged memory when
>> +     hardware support is present by use of the tunable
>> +     'glibc.memtag.enable'.  This includes the generation of tagged
>> +     memory when using the 'malloc' APIs.
>> +
>> +     At present only AArch64 platforms with MTE provide this
>> +     functionality, although the library will still operate (without
>> +     memory tagging) on older versions of the architecture.
>> +
>> +     The default is to disable support for memory tagging.
>> +
>>  '--disable-profile'
>>       Don't build libraries with profiling information.  You may want to
>>       use this option if you don't plan to do profiling.
>> diff --git a/config.h.in b/config.h.in
>> index b823c8e080..2f4c626c19 100644
>> --- a/config.h.in
>> +++ b/config.h.in
>> @@ -160,6 +160,9 @@
>>  /* Define if __stack_chk_guard canary should be randomized at program
>> startup.  */
>>  #undef ENABLE_STACKGUARD_RANDOMIZE
>>  
>> +/* Define if memory tagging support should be enabled.  */
>> +#undef _LIBC_MTAG
>> +
>>  /* Package description.  */
>>  #undef PKGVERSION
>>  
>> diff --git a/config.make.in b/config.make.in
>> index 1ac9417245..7ae27564fd 100644
>> --- a/config.make.in
>> +++ b/config.make.in
>> @@ -84,6 +84,8 @@ mach-interface-list = @mach_interface_list@
>>  
>>  experimental-malloc = @experimental_malloc@
>>  
>> +memory-tagging = @memory_tagging@
>> +
>>  nss-crypt = @libc_cv_nss_crypt@
>>  static-nss-crypt = @libc_cv_static_nss_crypt@
>>  
>> diff --git a/configure b/configure
>> index 4795e721e5..d22654739f 100755
>> --- a/configure
>> +++ b/configure
>> @@ -676,6 +676,7 @@ build_nscd
>>  libc_cv_static_nss_crypt
>>  libc_cv_nss_crypt
>>  build_crypt
>> +memory_tagging
>>  experimental_malloc
>>  enable_werror
>>  all_warnings
>> @@ -781,6 +782,7 @@ enable_all_warnings
>>  enable_werror
>>  enable_multi_arch
>>  enable_experimental_malloc
>> +enable_memory_tagging
>>  enable_crypt
>>  enable_nss_crypt
>>  enable_systemtap
>> @@ -1450,6 +1452,8 @@ Optional Features:
>>                            architectures
>>    --disable-experimental-malloc
>>                            disable experimental malloc features
>> +  --enable-memory-tagging enable memory tagging if supported by the
>> +                          architecture [default=no]
> 
> I wonder if that phrasing implies that the flag is disabled if memory
> tagging is not supported by the architecture.  The description in
> INSTALL (Enable memory tagging support on architectures that support it)
> seems a bit more precise.
> 
> Siddhesh

I'd be happy to change that to "Enable memory tagging on supported
architectures [default=no]".

R.
Siddhesh Poyarekar Nov. 25, 2020, 3:10 p.m. UTC | #3 
On 11/25/20 8:39 PM, Richard Earnshaw (lists) wrote:
> I'd be happy to change that to "Enable memory tagging on supported
> architectures [default=no]".

That's good, thanks.

Siddhesh
Adhemerval Zanella Nov. 25, 2020, 3:12 p.m. UTC | #4 
On 25/11/2020 12:05, Siddhesh Poyarekar wrote:
> On 11/23/20 9:12 PM, Richard Earnshaw via Libc-alpha wrote:
>>
>> This patch adds the configuration machinery to allow memory tagging to be
>> enabled from the command line via the configure option --enable-memory-tagging.
>>
>> The current default is off, though in time we may change that once the API
>> is more stable.
>> ---
>>   INSTALL             | 14 ++++++++++++++
>>   config.h.in         |  3 +++
>>   config.make.in      |  2 ++
>>   configure           | 17 +++++++++++++++++
>>   configure.ac        | 10 ++++++++++
>>   manual/install.texi | 13 +++++++++++++
>>   6 files changed, 59 insertions(+)
>>
>> diff --git a/INSTALL b/INSTALL
>> index 2b00f80df5..f2476df6c0 100644
>> --- a/INSTALL
>> +++ b/INSTALL
>> @@ -142,6 +142,20 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
>>       non-CET processors.  '--enable-cet' has been tested for i686,
>>       x86_64 and x32 on CET processors.
>>  
>> +'--enable-memory-tagging'
>> +     Enable memory tagging support on architectures that support it.
>> +     When the GNU C Library is built with this option then the resulting
>> +     library will be able to control the use of tagged memory when
>> +     hardware support is present by use of the tunable
>> +     'glibc.memtag.enable'.  This includes the generation of tagged
>> +     memory when using the 'malloc' APIs.
>> +
>> +     At present only AArch64 platforms with MTE provide this
>> +     functionality, although the library will still operate (without
>> +     memory tagging) on older versions of the architecture.
>> +
>> +     The default is to disable support for memory tagging.
>> +

Which is the downside of enabling it as default for AArch64 instead of
a configure option?  It would always be defined if --disable-tunables
would be set, so one option would to enable iff tunables is already
defined.

>>  '--disable-profile'
>>       Don't build libraries with profiling information.  You may want to
>>       use this option if you don't plan to do profiling.
>> diff --git a/config.h.in b/config.h.in
>> index b823c8e080..2f4c626c19 100644
>> --- a/config.h.in
>> +++ b/config.h.in
>> @@ -160,6 +160,9 @@
>>  /* Define if __stack_chk_guard canary should be randomized at program startup.  */
>>  #undef ENABLE_STACKGUARD_RANDOMIZE
>>  
>> +/* Define if memory tagging support should be enabled.  */
>> +#undef _LIBC_MTAG

The name is not really following the rest of other define, where
they either use HAVE_* or USE_*. Also, I think there is no need
to use an underscore prefix (it is usually used to define macro
guards).

>> +
>>  /* Package description.  */
>>  #undef PKGVERSION
>>  
>> diff --git a/config.make.in b/config.make.in
>> index 1ac9417245..7ae27564fd 100644
>> --- a/config.make.in
>> +++ b/config.make.in
>> @@ -84,6 +84,8 @@ mach-interface-list = @mach_interface_list@
>>  
>>  experimental-malloc = @experimental_malloc@
>>  
>> +memory-tagging = @memory_tagging@
>> +
>>  nss-crypt = @libc_cv_nss_crypt@
>>  static-nss-crypt = @libc_cv_static_nss_crypt@
>>  
>> diff --git a/configure b/configure
>> index 4795e721e5..d22654739f 100755
>> --- a/configure
>> +++ b/configure
>> @@ -676,6 +676,7 @@ build_nscd
>>  libc_cv_static_nss_crypt
>>  libc_cv_nss_crypt
>>  build_crypt
>> +memory_tagging
>>  experimental_malloc
>>  enable_werror
>>  all_warnings
>> @@ -781,6 +782,7 @@ enable_all_warnings
>>  enable_werror
>>  enable_multi_arch
>>  enable_experimental_malloc
>> +enable_memory_tagging
>>  enable_crypt
>>  enable_nss_crypt
>>  enable_systemtap
>> @@ -1450,6 +1452,8 @@ Optional Features:
>>                            architectures
>>    --disable-experimental-malloc
>>                            disable experimental malloc features
>> +  --enable-memory-tagging enable memory tagging if supported by the
>> +                          architecture [default=no]
> 
> I wonder if that phrasing implies that the flag is disabled if memory tagging is not supported by the architecture.  The description in INSTALL (Enable memory tagging support on architectures that support it) seems a bit more precise.
> 
> Siddhesh
Richard Earnshaw (lists) Nov. 25, 2020, 4:11 p.m. UTC | #5 
On 25/11/2020 15:12, Adhemerval Zanella via Libc-alpha wrote:
> 
> 
> On 25/11/2020 12:05, Siddhesh Poyarekar wrote:
>> On 11/23/20 9:12 PM, Richard Earnshaw via Libc-alpha wrote:
>>>
>>> This patch adds the configuration machinery to allow memory tagging to be
>>> enabled from the command line via the configure option --enable-memory-tagging.
>>>
>>> The current default is off, though in time we may change that once the API
>>> is more stable.
>>> ---
>>>   INSTALL             | 14 ++++++++++++++
>>>   config.h.in         |  3 +++
>>>   config.make.in      |  2 ++
>>>   configure           | 17 +++++++++++++++++
>>>   configure.ac        | 10 ++++++++++
>>>   manual/install.texi | 13 +++++++++++++
>>>   6 files changed, 59 insertions(+)
>>>
>>> diff --git a/INSTALL b/INSTALL
>>> index 2b00f80df5..f2476df6c0 100644
>>> --- a/INSTALL
>>> +++ b/INSTALL
>>> @@ -142,6 +142,20 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
>>>       non-CET processors.  '--enable-cet' has been tested for i686,
>>>       x86_64 and x32 on CET processors.
>>>  
>>> +'--enable-memory-tagging'
>>> +     Enable memory tagging support on architectures that support it.
>>> +     When the GNU C Library is built with this option then the resulting
>>> +     library will be able to control the use of tagged memory when
>>> +     hardware support is present by use of the tunable
>>> +     'glibc.memtag.enable'.  This includes the generation of tagged
>>> +     memory when using the 'malloc' APIs.
>>> +
>>> +     At present only AArch64 platforms with MTE provide this
>>> +     functionality, although the library will still operate (without
>>> +     memory tagging) on older versions of the architecture.
>>> +
>>> +     The default is to disable support for memory tagging.
>>> +
> 
> Which is the downside of enabling it as default for AArch64 instead of
> a configure option?  It would always be defined if --disable-tunables
> would be set, so one option would to enable iff tunables is already
> defined.


The default of off at present is largely due to this being new and I
didn't want to risk (too much) disturbing existing uses.  My hope is
that the option default will change to on at some point in the
not-too-distant future.

> 
>>>  '--disable-profile'
>>>       Don't build libraries with profiling information.  You may want to
>>>       use this option if you don't plan to do profiling.
>>> diff --git a/config.h.in b/config.h.in
>>> index b823c8e080..2f4c626c19 100644
>>> --- a/config.h.in
>>> +++ b/config.h.in
>>> @@ -160,6 +160,9 @@
>>>  /* Define if __stack_chk_guard canary should be randomized at program startup.  */
>>>  #undef ENABLE_STACKGUARD_RANDOMIZE
>>>  
>>> +/* Define if memory tagging support should be enabled.  */
>>> +#undef _LIBC_MTAG
> 
> The name is not really following the rest of other define, where
> they either use HAVE_* or USE_*. Also, I think there is no need
> to use an underscore prefix (it is usually used to define macro
> guards).

It's mainly just sed work to change the name.  Which do you want?  HAVE_
or USE_ ?

> 
>>> +
>>>  /* Package description.  */
>>>  #undef PKGVERSION
>>>  
>>> diff --git a/config.make.in b/config.make.in
>>> index 1ac9417245..7ae27564fd 100644
>>> --- a/config.make.in
>>> +++ b/config.make.in
>>> @@ -84,6 +84,8 @@ mach-interface-list = @mach_interface_list@
>>>  
>>>  experimental-malloc = @experimental_malloc@
>>>  
>>> +memory-tagging = @memory_tagging@
>>> +
>>>  nss-crypt = @libc_cv_nss_crypt@
>>>  static-nss-crypt = @libc_cv_static_nss_crypt@
>>>  
>>> diff --git a/configure b/configure
>>> index 4795e721e5..d22654739f 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -676,6 +676,7 @@ build_nscd
>>>  libc_cv_static_nss_crypt
>>>  libc_cv_nss_crypt
>>>  build_crypt
>>> +memory_tagging
>>>  experimental_malloc
>>>  enable_werror
>>>  all_warnings
>>> @@ -781,6 +782,7 @@ enable_all_warnings
>>>  enable_werror
>>>  enable_multi_arch
>>>  enable_experimental_malloc
>>> +enable_memory_tagging
>>>  enable_crypt
>>>  enable_nss_crypt
>>>  enable_systemtap
>>> @@ -1450,6 +1452,8 @@ Optional Features:
>>>                            architectures
>>>    --disable-experimental-malloc
>>>                            disable experimental malloc features
>>> +  --enable-memory-tagging enable memory tagging if supported by the
>>> +                          architecture [default=no]
>>
>> I wonder if that phrasing implies that the flag is disabled if memory tagging is not supported by the architecture.  The description in INSTALL (Enable memory tagging support on architectures that support it) seems a bit more precise.
>>
>> Siddhesh

R.
Adhemerval Zanella Nov. 25, 2020, 4:40 p.m. UTC | #6 
On 25/11/2020 13:11, Richard Earnshaw (lists) wrote:
> On 25/11/2020 15:12, Adhemerval Zanella via Libc-alpha wrote:
>>
>>
>> On 25/11/2020 12:05, Siddhesh Poyarekar wrote:
>>> On 11/23/20 9:12 PM, Richard Earnshaw via Libc-alpha wrote:
>>>>
>>>> This patch adds the configuration machinery to allow memory tagging to be
>>>> enabled from the command line via the configure option --enable-memory-tagging.
>>>>
>>>> The current default is off, though in time we may change that once the API
>>>> is more stable.
>>>> ---
>>>>   INSTALL             | 14 ++++++++++++++
>>>>   config.h.in         |  3 +++
>>>>   config.make.in      |  2 ++
>>>>   configure           | 17 +++++++++++++++++
>>>>   configure.ac        | 10 ++++++++++
>>>>   manual/install.texi | 13 +++++++++++++
>>>>   6 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/INSTALL b/INSTALL
>>>> index 2b00f80df5..f2476df6c0 100644
>>>> --- a/INSTALL
>>>> +++ b/INSTALL
>>>> @@ -142,6 +142,20 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
>>>>       non-CET processors.  '--enable-cet' has been tested for i686,
>>>>       x86_64 and x32 on CET processors.
>>>>  
>>>> +'--enable-memory-tagging'
>>>> +     Enable memory tagging support on architectures that support it.
>>>> +     When the GNU C Library is built with this option then the resulting
>>>> +     library will be able to control the use of tagged memory when
>>>> +     hardware support is present by use of the tunable
>>>> +     'glibc.memtag.enable'.  This includes the generation of tagged
>>>> +     memory when using the 'malloc' APIs.
>>>> +
>>>> +     At present only AArch64 platforms with MTE provide this
>>>> +     functionality, although the library will still operate (without
>>>> +     memory tagging) on older versions of the architecture.
>>>> +
>>>> +     The default is to disable support for memory tagging.
>>>> +
>>
>> Which is the downside of enabling it as default for AArch64 instead of
>> a configure option?  It would always be defined if --disable-tunables
>> would be set, so one option would to enable iff tunables is already
>> defined.
> 
> 
> The default of off at present is largely due to this being new and I
> didn't want to risk (too much) disturbing existing uses.  My hope is
> that the option default will change to on at some point in the
> not-too-distant future.

Right, I am asking because I would like avoid adding another build permutation
which would another testing effort.  To fully test this patch, it already 
requires a MTE enable hardware or emulation; I trying to going from 4 
permutations (default glibc/no-MTE hw, MTE glibc/no-MTE hw, default glibc/MTE hw,
MTE glibc/MTE hw) to just 2 (glibc/no-MTE hw, glibc/MTE hw).

> 
>>
>>>>  '--disable-profile'
>>>>       Don't build libraries with profiling information.  You may want to
>>>>       use this option if you don't plan to do profiling.
>>>> diff --git a/config.h.in b/config.h.in
>>>> index b823c8e080..2f4c626c19 100644
>>>> --- a/config.h.in
>>>> +++ b/config.h.in
>>>> @@ -160,6 +160,9 @@
>>>>  /* Define if __stack_chk_guard canary should be randomized at program startup.  */
>>>>  #undef ENABLE_STACKGUARD_RANDOMIZE
>>>>  
>>>> +/* Define if memory tagging support should be enabled.  */
>>>> +#undef _LIBC_MTAG
>>
>> The name is not really following the rest of other define, where
>> they either use HAVE_* or USE_*. Also, I think there is no need
>> to use an underscore prefix (it is usually used to define macro
>> guards).
> 
> It's mainly just sed work to change the name.  Which do you want?  HAVE_
> or USE_ ?

I think USE_ would make more sense here, but I don't have a strong opinion.
diff mbox series

Patch

diff --git a/INSTALL b/INSTALL
index 2b00f80df5..f2476df6c0 100644
--- a/INSTALL
+++ b/INSTALL
@@ -142,6 +142,20 @@  if 'CFLAGS' is specified it must enable optimization.  For example:
      non-CET processors.  '--enable-cet' has been tested for i686,
      x86_64 and x32 on CET processors.
 
+'--enable-memory-tagging'
+     Enable memory tagging support on architectures that support it.
+     When the GNU C Library is built with this option then the resulting
+     library will be able to control the use of tagged memory when
+     hardware support is present by use of the tunable
+     'glibc.memtag.enable'.  This includes the generation of tagged
+     memory when using the 'malloc' APIs.
+
+     At present only AArch64 platforms with MTE provide this
+     functionality, although the library will still operate (without
+     memory tagging) on older versions of the architecture.
+
+     The default is to disable support for memory tagging.
+
 '--disable-profile'
      Don't build libraries with profiling information.  You may want to
      use this option if you don't plan to do profiling.
diff --git a/config.h.in b/config.h.in
index b823c8e080..2f4c626c19 100644
--- a/config.h.in
+++ b/config.h.in
@@ -160,6 +160,9 @@ 
 /* Define if __stack_chk_guard canary should be randomized at program startup.  */
 #undef ENABLE_STACKGUARD_RANDOMIZE
 
+/* Define if memory tagging support should be enabled.  */
+#undef _LIBC_MTAG
+
 /* Package description.  */
 #undef PKGVERSION
 
diff --git a/config.make.in b/config.make.in
index 1ac9417245..7ae27564fd 100644
--- a/config.make.in
+++ b/config.make.in
@@ -84,6 +84,8 @@  mach-interface-list = @mach_interface_list@
 
 experimental-malloc = @experimental_malloc@
 
+memory-tagging = @memory_tagging@
+
 nss-crypt = @libc_cv_nss_crypt@
 static-nss-crypt = @libc_cv_static_nss_crypt@
 
diff --git a/configure b/configure
index 4795e721e5..d22654739f 100755
--- a/configure
+++ b/configure
@@ -676,6 +676,7 @@  build_nscd
 libc_cv_static_nss_crypt
 libc_cv_nss_crypt
 build_crypt
+memory_tagging
 experimental_malloc
 enable_werror
 all_warnings
@@ -781,6 +782,7 @@  enable_all_warnings
 enable_werror
 enable_multi_arch
 enable_experimental_malloc
+enable_memory_tagging
 enable_crypt
 enable_nss_crypt
 enable_systemtap
@@ -1450,6 +1452,8 @@  Optional Features:
                           architectures
   --disable-experimental-malloc
                           disable experimental malloc features
+  --enable-memory-tagging enable memory tagging if supported by the
+                          architecture [default=no]
   --disable-crypt         do not build nor install the passphrase hashing
                           library, libcrypt
   --enable-nss-crypt      enable libcrypt to use nss
@@ -3519,6 +3523,19 @@  fi
 
 
 
+# Check whether --enable-memory-tagging was given.
+if test "${enable_memory_tagging+set}" = set; then :
+  enableval=$enable_memory_tagging; memory_tagging=$enableval
+else
+  memory_tagging=no
+fi
+
+if test "$memory_tagging" = yes; then
+  $as_echo "#define _LIBC_MTAG 1" >>confdefs.h
+
+fi
+
+
 # Check whether --enable-crypt was given.
 if test "${enable_crypt+set}" = set; then :
   enableval=$enable_crypt; build_crypt=$enableval
diff --git a/configure.ac b/configure.ac
index 93e68fb696..78af01d05b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -311,6 +311,16 @@  AC_ARG_ENABLE([experimental-malloc],
 	      [experimental_malloc=yes])
 AC_SUBST(experimental_malloc)
 
+AC_ARG_ENABLE([memory-tagging],
+	      AC_HELP_STRING([--enable-memory-tagging],
+			     [enable memory tagging if supported by the architecture @<:@default=no@:>@]),
+	      [memory_tagging=$enableval],
+	      [memory_tagging=no])
+if test "$memory_tagging" = yes; then
+  AC_DEFINE(_LIBC_MTAG)
+fi
+AC_SUBST(memory_tagging)
+
 AC_ARG_ENABLE([crypt],
               AC_HELP_STRING([--disable-crypt],
                              [do not build nor install the passphrase hashing library, libcrypt]),
diff --git a/manual/install.texi b/manual/install.texi
index 2e164476d5..30fb6aaa46 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -171,6 +171,19 @@  NOTE: @option{--enable-cet} has been tested for i686, x86_64 and x32
 on non-CET processors.  @option{--enable-cet} has been tested for
 i686, x86_64 and x32 on CET processors.
 
+@item --enable-memory-tagging
+Enable memory tagging support on architectures that support it.  When
+@theglibc{} is built with this option then the resulting library will
+be able to control the use of tagged memory when hardware support is
+present by use of the tunable @samp{glibc.memtag.enable}.  This includes
+the generation of tagged memory when using the @code{malloc} APIs.
+
+At present only AArch64 platforms with MTE provide this functionality,
+although the library will still operate (without memory tagging) on
+older versions of the architecture.
+
+The default is to disable support for memory tagging.
+
 @item --disable-profile
 Don't build libraries with profiling information.  You may want to use
 this option if you don't plan to do profiling.