[PATCH v3 0/1] x86/shstk: don't create the shadow stack for PF_USER_WORKERs

[PATCH v3 0/1] x86/shstk: don't create the shadow stack for PF_USER_WORKERs

[Oleg Nesterov]

Dave, et al, please review.

Our discussion with Rick was confusing and we can't convince each other.
Perhaps this is my fault. So let me resend 4/5 from this series

	[PATCH v2 0/5] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER) in .regset_get() paths
	https://lore.kernel.org/all/20250822153603.GA27103@redhat.com/

as a separate patch. I tried to update the changelog.

Again, to me it looks like a simple cleanup which makes sense regardless,
but please correct me if I am wrong.

Oleg.

[PATCH v3 1/1] x86/shstk: don't create the shadow stack for PF_USER_WORKERs

[Oleg Nesterov]

If a features_enabled(ARCH_SHSTK_SHSTK) userspace thread creates a
PF_USER_WORKER thread, shstk_alloc_thread_stack() allocates a shadow
stack for no reason, the new (kernel) thread will never return to usermode.

Another problem is that the current logic looks simply wrong. In this case
fpu_clone() won't call update_fpu_shstk(), so xstate->user_ssp won't be
initialized.

But since the copy_thread() paths do not clear the ARCH_SHSTK_SHSTK flag
copied by arch_dup_task_struct(), ssp_active(PF_USER_WORKER) will return
true in ssp_get(), so ssp_get() will try to report cetregs->user_ssp which
can't be correct.

Add the new "bool minimal = !!args->fn" argument (which matches that of
fpu_clone()) to shstk_alloc_thread_stack() and change it to not allocate
shstk and to clear ARCH_SHSTK_SHSTK if minimal == true.

With this patch ssp_get() and ssp_set() will return -ENODEV right after
the ssp_active() check if target->flags & PF_USER_WORKER.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 arch/x86/include/asm/shstk.h | 4 ++--
 arch/x86/kernel/process.c    | 2 +-
 arch/x86/kernel/shstk.c      | 9 +++++++--
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/shstk.h b/arch/x86/include/asm/shstk.h
index ba6f2fe43848..a4ee2baab51c 100644
--- a/arch/x86/include/asm/shstk.h
+++ b/arch/x86/include/asm/shstk.h
@@ -17,7 +17,7 @@ struct thread_shstk {
 long shstk_prctl(struct task_struct *task, int option, unsigned long arg2);
 void reset_thread_features(void);
 unsigned long shstk_alloc_thread_stack(struct task_struct *p, unsigned long clone_flags,
-				       unsigned long stack_size);
+				       bool minimal, unsigned long stack_size);
 void shstk_free(struct task_struct *p);
 int setup_signal_shadow_stack(struct ksignal *ksig);
 int restore_signal_shadow_stack(void);
@@ -28,7 +28,7 @@ static inline long shstk_prctl(struct task_struct *task, int option,
 			       unsigned long arg2) { return -EINVAL; }
 static inline void reset_thread_features(void) {}
 static inline unsigned long shstk_alloc_thread_stack(struct task_struct *p,
-						     unsigned long clone_flags,
+						     unsigned long clone_flags, bool minimal,
 						     unsigned long stack_size) { return 0; }
 static inline void shstk_free(struct task_struct *p) {}
 static inline int setup_signal_shadow_stack(struct ksignal *ksig) { return 0; }
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1b7960cf6eb0..e932e0e53972 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -209,7 +209,7 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
 	 * is disabled, new_ssp will remain 0, and fpu_clone() will know not to
 	 * update it.
 	 */
-	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->stack_size);
+	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->fn, args->stack_size);
 	if (IS_ERR_VALUE(new_ssp))
 		return PTR_ERR((void *)new_ssp);
 
diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
index 2ddf23387c7e..6c8c4593e202 100644
--- a/arch/x86/kernel/shstk.c
+++ b/arch/x86/kernel/shstk.c
@@ -192,7 +192,7 @@ void reset_thread_features(void)
 }
 
 unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long clone_flags,
-				       unsigned long stack_size)
+				       bool minimal, unsigned long stack_size)
 {
 	struct thread_shstk *shstk = &tsk->thread.shstk;
 	unsigned long addr, size;
@@ -208,8 +208,13 @@ unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long cl
 	 * For CLONE_VFORK the child will share the parents shadow stack.
 	 * Make sure to clear the internal tracking of the thread shadow
 	 * stack so the freeing logic run for child knows to leave it alone.
+	 *
+	 * If minimal == true, the new kernel thread cloned from userspace
+	 * thread will never return to usermode.
 	 */
-	if (clone_flags & CLONE_VFORK) {
+	if ((clone_flags & CLONE_VFORK) || minimal) {
+		if (minimal)
+			tsk->thread.features &= ~ARCH_SHSTK_SHSTK;
 		shstk->base = 0;
 		shstk->size = 0;
 		return 0;
-- 
2.25.1.362.g51ebf55

Re: [PATCH v3 1/1] x86/shstk: don't create the shadow stack for PF_USER_WORKERs

[Dave Hansen]

On 9/3/25 06:42, Oleg Nesterov wrote:
>  arch/x86/include/asm/shstk.h | 4 ++--
>  arch/x86/kernel/process.c    | 2 +-
>  arch/x86/kernel/shstk.c      | 9 +++++++--
>  3 files changed, 10 insertions(+), 5 deletions(-)

That's not a great diffstat for a "cleanup". It's also not fixing any
end-user-visible issues as far as I can tell.

>  static inline void shstk_free(struct task_struct *p) {}
>  static inline int setup_signal_shadow_stack(struct ksignal *ksig) { return 0; }
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 1b7960cf6eb0..e932e0e53972 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -209,7 +209,7 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
>  	 * is disabled, new_ssp will remain 0, and fpu_clone() will know not to
>  	 * update it.
>  	 */
> -	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->stack_size);
> +	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->fn, args->stack_size);

Passing 'args->fn' as a 'bool' argument is a bit cruel, don't you think?

>  	if (IS_ERR_VALUE(new_ssp))
>  		return PTR_ERR((void *)new_ssp);
>  
> diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
> index 2ddf23387c7e..6c8c4593e202 100644
> --- a/arch/x86/kernel/shstk.c
> +++ b/arch/x86/kernel/shstk.c
> @@ -192,7 +192,7 @@ void reset_thread_features(void)
>  }
>  
>  unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long clone_flags,
> -				       unsigned long stack_size)
> +				       bool minimal, unsigned long stack_size)
'minimal' is an awfully meaningless name for this.

This doesn't clean things up or clarify the situation enough to make me
want to apply it immediately.

Re: [PATCH v3 1/1] x86/shstk: don't create the shadow stack for PF_USER_WORKERs

[Mark Brown]

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

On Wed, Sep 03, 2025 at 09:14:30AM -0700, Dave Hansen wrote:
> On 9/3/25 06:42, Oleg Nesterov wrote:

> >  arch/x86/include/asm/shstk.h | 4 ++--
> >  arch/x86/kernel/process.c    | 2 +-
> >  arch/x86/kernel/shstk.c      | 9 +++++++--
> >  3 files changed, 10 insertions(+), 5 deletions(-)

> That's not a great diffstat for a "cleanup". It's also not fixing any
> end-user-visible issues as far as I can tell.

...

> This doesn't clean things up or clarify the situation enough to make me
> want to apply it immediately.

I think the suggestion from one of the earlier discussions that if we
want to do this we roll it into a more general pulling out of shared
shadow stack code into the core makes sense here.  There's clearly a lot
of overlap between the three shadow stack implementations we have, and
an optimisation like this really shouldn't be arch specific.  I do
intend to poke at this whenever my clone3() series goes in.

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

Re: [PATCH v3 1/1] x86/shstk: don't create the shadow stack for PF_USER_WORKERs

[Oleg Nesterov]

On 09/03, Dave Hansen wrote:
>
> On 9/3/25 06:42, Oleg Nesterov wrote:
> >  arch/x86/include/asm/shstk.h | 4 ++--
> >  arch/x86/kernel/process.c    | 2 +-
> >  arch/x86/kernel/shstk.c      | 9 +++++++--
> >  3 files changed, 10 insertions(+), 5 deletions(-)
>
> That's not a great diffstat for a "cleanup". It's also not fixing any
> end-user-visible issues as far as I can tell.

Well, from the changelog:

	Another problem is that the current logic looks simply wrong. In this case
	fpu_clone() won't call update_fpu_shstk(), so xstate->user_ssp won't be
	initialized.

	But since the copy_thread() paths do not clear the ARCH_SHSTK_SHSTK flag
	copied by arch_dup_task_struct(), ssp_active(PF_USER_WORKER) will return
	true in ssp_get(), so ssp_get() will try to report cetregs->user_ssp which
	can't be correct.

this doesn't look right to me.

> > -	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->stack_size);
> > +	new_ssp = shstk_alloc_thread_stack(p, clone_flags, args->fn, args->stack_size);
>
> Passing 'args->fn' as a 'bool' argument is a bit cruel, don't you think?

Yes, and

> >  unsigned long shstk_alloc_thread_stack(struct task_struct *tsk, unsigned long clone_flags,
> > -				       unsigned long stack_size)
> > +				       bool minimal, unsigned long stack_size)
> 'minimal' is an awfully meaningless name for this.

yes.

But please note that fpu_clone() has the same "bool minimal" argument passed
as "args->fn". I even mentioned this in the changelog, this patch tries to
mimic the existing code. But of course I can change it. Can you suggest a
better name?

Oleg.