linux-kernel - Re: [PATCH v3 1/1] x86/shstk: don't create the shadow stack for PF_USER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250904091015.GC27255@redhat.com>
Date: Thu, 4 Sep 2025 11:10:16 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Deepak Gupta <debug@...osinc.com>, "H. Peter Anvin" <hpa@...or.com>,
	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mark Brown <broonie@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Sohil Mehta <sohil.mehta@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH v3 1/1] x86/shstk: don't create the shadow stack for
 PF_USER_WORKERs

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.