diff mbox series

aarch64: Use future HWCAP2_MTE in ifunc resolver

Message ID 20200727092649.31740-1-szabolcs.nagy@arm.com
State Committed
Commit 2dc33b928b389f50e7fd8cadd952b79112a071ab
Headers
Series aarch64: Use future HWCAP2_MTE in ifunc resolver |

Commit Message

Szabolcs Nagy July 27, 2020, 9:26 a.m. UTC 
  Make glibc MTE-safe on systems where MTE is available. This allows
using heap tagging with an LD_PRELOADed malloc implementation that
enables MTE. We don't document this as guaranteed contract yet, so
glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs
certainly aren't). This is mainly for testing and debugging.

The HWCAP flag is not exposed in public headers until Linux adds it
to its uapi. The HWCAP value reservation will be in Linux 5.9.

---
I'd like to commit this for 2.32, it is safe even if the hwcap value
changes because there is no mte safety guarantee (but there is no
reason for linux to change the value).

linux commit:
http://git.kernel.org/arm64/c/a46cec12f4a5

tested in qemu.
---
 sysdeps/aarch64/multiarch/strlen.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Comments

Florian Weimer July 27, 2020, 9:54 a.m. UTC | #1 
* Szabolcs Nagy:

> Make glibc MTE-safe on systems where MTE is available. This allows
> using heap tagging with an LD_PRELOADed malloc implementation that
> enables MTE. We don't document this as guaranteed contract yet, so
> glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs
> certainly aren't). This is mainly for testing and debugging.
>
> The HWCAP flag is not exposed in public headers until Linux adds it
> to its uapi. The HWCAP value reservation will be in Linux 5.9.

It's not yet in Linus' tree, though?

I think this is safe because the MTE code will run just fine on non-MTE
systems (if the bit is repurposed after all), right?

Thanks,
Florian
Szabolcs Nagy July 27, 2020, 11:42 a.m. UTC | #2 
The 07/27/2020 11:54, Florian Weimer wrote:
> * Szabolcs Nagy:
> 
> > Make glibc MTE-safe on systems where MTE is available. This allows
> > using heap tagging with an LD_PRELOADed malloc implementation that
> > enables MTE. We don't document this as guaranteed contract yet, so
> > glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs
> > certainly aren't). This is mainly for testing and debugging.
> >
> > The HWCAP flag is not exposed in public headers until Linux adds it
> > to its uapi. The HWCAP value reservation will be in Linux 5.9.
> 
> It's not yet in Linus' tree, though?
> 
> I think this is safe because the MTE code will run just fine on non-MTE
> systems (if the bit is repurposed after all), right?

yes.
Florian Weimer July 27, 2020, 11:47 a.m. UTC | #3 
* Szabolcs Nagy:

> The 07/27/2020 11:54, Florian Weimer wrote:
>> * Szabolcs Nagy:
>> 
>> > Make glibc MTE-safe on systems where MTE is available. This allows
>> > using heap tagging with an LD_PRELOADed malloc implementation that
>> > enables MTE. We don't document this as guaranteed contract yet, so
>> > glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs
>> > certainly aren't). This is mainly for testing and debugging.
>> >
>> > The HWCAP flag is not exposed in public headers until Linux adds it
>> > to its uapi. The HWCAP value reservation will be in Linux 5.9.
>> 
>> It's not yet in Linus' tree, though?
>> 
>> I think this is safe because the MTE code will run just fine on non-MTE
>> systems (if the bit is repurposed after all), right?
>
> yes.

Okay, then this is fine for glibc 2.32.  Thanks.

Florian
Adhemerval Zanella July 27, 2020, 1:52 p.m. UTC | #4 
On 27/07/2020 06:26, Szabolcs Nagy wrote:
> Make glibc MTE-safe on systems where MTE is available. This allows
> using heap tagging with an LD_PRELOADed malloc implementation that
> enables MTE. We don't document this as guaranteed contract yet, so
> glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs
> certainly aren't). This is mainly for testing and debugging.
> 
> The HWCAP flag is not exposed in public headers until Linux adds it
> to its uapi. The HWCAP value reservation will be in Linux 5.9.
> 
> ---
> I'd like to commit this for 2.32, it is safe even if the hwcap value
> changes because there is no mte safety guarantee (but there is no
> reason for linux to change the value).
> 
> linux commit:
> http://git.kernel.org/arm64/c/a46cec12f4a5
> 
> tested in qemu.
> ---
>  sysdeps/aarch64/multiarch/strlen.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/sysdeps/aarch64/multiarch/strlen.c b/sysdeps/aarch64/multiarch/strlen.c
> index 7c0352dd87..9440decf75 100644
> --- a/sysdeps/aarch64/multiarch/strlen.c
> +++ b/sysdeps/aarch64/multiarch/strlen.c
> @@ -26,8 +26,14 @@
>  # include <string.h>
>  # include <init-arch.h>
>  
> -/* This should check HWCAP_MTE when it is available.  */
> -#define MTE_ENABLED() (false)
> +/* This should check HWCAP2_MTE when it is available: current
> +   linux kernel does not expose it, but its value is reserved.
> +   This is needed to make glibc MTE-safe on future systems in
> +   case user code enables MTE. The ABI contract for enabling

Double space after period.  Besides it, the patch is ok.

> +   MTE is not yet specified, but it can be useful for at least
> +   debugging which does not need a contract.  */
> +#define FUTURE_HWCAP2_MTE (1 << 18)
> +#define MTE_ENABLED() (GLRO(dl_hwcap2) & FUTURE_HWCAP2_MTE)
>  
>  extern __typeof (__redirect_strlen) __strlen;
>  
>
diff mbox series

Patch

diff --git a/sysdeps/aarch64/multiarch/strlen.c b/sysdeps/aarch64/multiarch/strlen.c
index 7c0352dd87..9440decf75 100644
--- a/sysdeps/aarch64/multiarch/strlen.c
+++ b/sysdeps/aarch64/multiarch/strlen.c
@@ -26,8 +26,14 @@ 
 # include <string.h>
 # include <init-arch.h>
 
-/* This should check HWCAP_MTE when it is available.  */
-#define MTE_ENABLED() (false)
+/* This should check HWCAP2_MTE when it is available: current
+   linux kernel does not expose it, but its value is reserved.
+   This is needed to make glibc MTE-safe on future systems in
+   case user code enables MTE. The ABI contract for enabling
+   MTE is not yet specified, but it can be useful for at least
+   debugging which does not need a contract.  */
+#define FUTURE_HWCAP2_MTE (1 << 18)
+#define MTE_ENABLED() (GLRO(dl_hwcap2) & FUTURE_HWCAP2_MTE)
 
 extern __typeof (__redirect_strlen) __strlen;