[PATCH] arm64/ptrace: Ensure that the task sees ZT writes on first use

[PATCH] arm64/ptrace: Ensure that the task sees ZT writes on first use

[Mark Brown]

When the value of ZT is set via ptrace we don't disable traps for SME.
This means that when a the task has never used SME before then the value
set via ptrace will never be seen by the target task since it will
trigger a SME access trap which will flush the register state.

Disable SME traps when setting ZT, this means we also need to allocate
storage for SVE if it is not already allocated, for the benefit of
streaming SVE.

Fixes: f90b529bcbe5 ("arm64/sme: Implement ZT0 ptrace support")
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/ptrace.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 5b9b4305248b..254eb37e1f07 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1170,6 +1170,11 @@ static int zt_set(struct task_struct *target,
 	if (!system_supports_sme2())
 		return -EINVAL;
 
+	/* Ensure SVE storage in case this is first use of SME */
+	sve_alloc(target, false);
+	if (!target->thread.sve_state)
+		return -ENOMEM;
+
 	if (!thread_za_enabled(&target->thread)) {
 		sme_alloc(target);
 		if (!target->thread.sme_state)
@@ -1182,6 +1187,8 @@ static int zt_set(struct task_struct *target,
 	if (ret == 0)
 		target->thread.svcr |= SVCR_ZA_MASK;
 
+	set_tsk_thread_flag(target, TIF_SME);
+
 	fpsimd_flush_task_state(target);
 
 	return ret;

---
base-commit: 2ccdd1b13c591d306f0401d98dedc4bdcd02b421
change-id: 20230814-arm64-zt-ptrace-first-use-e6595b2162fc

Best regards,
-- 
Mark Brown <broonie@kernel.org>

Re: [PATCH] arm64/ptrace: Ensure that the task sees ZT writes on first use

[Will Deacon]

On Mon, Aug 14, 2023 at 10:27:51PM +0100, Mark Brown wrote:
> When the value of ZT is set via ptrace we don't disable traps for SME.
> This means that when a the task has never used SME before then the value
> set via ptrace will never be seen by the target task since it will
> trigger a SME access trap which will flush the register state.
> 
> Disable SME traps when setting ZT, this means we also need to allocate
> storage for SVE if it is not already allocated, for the benefit of
> streaming SVE.
> 
> Fixes: f90b529bcbe5 ("arm64/sme: Implement ZT0 ptrace support")
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/kernel/ptrace.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 5b9b4305248b..254eb37e1f07 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -1170,6 +1170,11 @@ static int zt_set(struct task_struct *target,
>  	if (!system_supports_sme2())
>  		return -EINVAL;
>  
> +	/* Ensure SVE storage in case this is first use of SME */
> +	sve_alloc(target, false);
> +	if (!target->thread.sve_state)
> +		return -ENOMEM;
> +
>  	if (!thread_za_enabled(&target->thread)) {
>  		sme_alloc(target);
>  		if (!target->thread.sme_state)
> @@ -1182,6 +1187,8 @@ static int zt_set(struct task_struct *target,
>  	if (ret == 0)
>  		target->thread.svcr |= SVCR_ZA_MASK;
>  
> +	set_tsk_thread_flag(target, TIF_SME);

Hmm, this is now weirdly inconsistent with za_set(), which doesn't touch
the thread flag unless the regset copy succeeds. Is that intentional?

Will

Re: [PATCH] arm64/ptrace: Ensure that the task sees ZT writes on first use

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Wed, Aug 16, 2023 at 03:22:19PM +0100, Will Deacon wrote:
> On Mon, Aug 14, 2023 at 10:27:51PM +0100, Mark Brown wrote:

> > @@ -1182,6 +1187,8 @@ static int zt_set(struct task_struct *target,
> >  	if (ret == 0)
> >  		target->thread.svcr |= SVCR_ZA_MASK;
> >  
> > +	set_tsk_thread_flag(target, TIF_SME);

> Hmm, this is now weirdly inconsistent with za_set(), which doesn't touch
> the thread flag unless the regset copy succeeds. Is that intentional?

Not particularly, it's just a product of the more complex parsing that
ZA needs due to the variable size and optional payload.  Either way is
fine so long as we allocated the storage but it would be better if they
were consistent, I'll update this to match what ZA does.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]