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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Fri, 2025-08-15 at 18:54 +0200, Oleg Nesterov wrote:
> > So what are we trying to do for PF_USER_WORKER? Prevent them from wasting a
> > VMA
> > with an unused shadow stack? Or set PF_USER_WORKER's aside from the logic
> > that
> > is about more than protecting the individual thread in the process?
> 
> Let me quote my answer to Mark:
> 
> 	The fact that a kernel thread can have the pointless ARCH_SHSTK_SHSTK
> is
> 	the only reason I know why x86_task_fpu(PF_USER_WORKER) has to work.

Maybe you can explain the exact failure mode here? ARCH_SHSTK_SHSTK isn't part
of the FPU infrastructure, so maybe you can explain how there is some cascade.

> 
> 	I'd like to make this logic consistent with PF_KTHREAD, and in the
> longer
> 	term change the x86 FPU code so that the kernel threads can run
> without
> 	without "struct fpu" attached to task_struct.

For PF_USER_WORKER it still has access to the user MM, right? Shouldn't it
inherit PKRU from the parent?

Stop me if I'm telling you something you already know... For better or worse,
the x86 FPU state has grown from the classic "extra math registers", to include
other things like PKRU and supervisor state. Supervisor state controls other
thread specific state that *only* the kernel is supposed to have complete access
to. Some of the xfeatures are even about saving and restoring state that *only*
affects the kernel. So I think each xfeature needs to be evaluated, and they are
all annoyingly different. I think LBR works in the kernel too?

> 
> And again, please see
> 
> 	Warning from x86_task_fpu()
> 	https://lore.kernel.org/all/aJVuZZgYjEMxiUYq@ly-workstation/
> 
> 	PF_USER_WORKERs and shadow stack
> 	https://lore.kernel.org/all/20250813162824.GA15234@redhat.com/
> 
> and 6/6 in this series.

I kind of think it would be more appropriate for you to explain more about what
you are trying to do. I've read three things:
 - Prevent wasting a shstk VMA (which Dave suggested maybe wasn't worth it)
 - Prevent issue around update_fpu_shstk(), which I'm not sure is an issue
 - Prevent ptrace from setting FPU state on user workers because it caused
problems (details unclear), by changing the FPU design in a way that apparently
has impacts across FPU-using features (unclear why this is the best way to
prevent it)

TBH, based on my current understanding, all three sound dubious to me. Let's get
on the same page as far as the goals before we discuss shstk changes further.
You might be aware that the x86 FPU is seen as too complex already and so adding
special cases tends to have a high bar. So consider making a strong, clear
justification for the overall problem/solution you have in mind.