| Message ID | 20200727092649.31740-1-szabolcs.nagy@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | aarch64: Use future HWCAP2_MTE in ifunc resolver | expand |
* 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
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.
* 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
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 --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;