linux-kernel - Re: [PATCH v2 0/5] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER) in .regset

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: <20250904134438.GA23718@redhat.com>
Date: Thu, 4 Sep 2025 15:44:39 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "debug@...osinc.com" <debug@...osinc.com>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"bp@...en8.de" <bp@...en8.de>,
	"broonie@...nel.org" <broonie@...nel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"Mehta, Sohil" <sohil.mehta@...el.com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v2 0/5] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER)
 in .regset_get() paths

On 09/03, Edgecombe, Rick P wrote:
>
> On Wed, 2025-09-03 at 11:54 +0200, Oleg Nesterov wrote:
> > > Hmm, I actually do see a potential concrete issue...
> > >
> > > fpu_clone() will wipe out the FPU state for PF_USER_WORKER, which means if
> > > xsaves decides to use the init optimization for CET, "get_xsave_addr(xsave,
> > > XFEATURE_CET_USER)" could return NULL and trigger a warning.
> >
> > Even if get_xsave_addr() returns a valid pointer, what is the point to try to
> > report cetregs->user_ssp which doesn't match the reality?
> > Again, update_fpu_shstk() was not called, ->user_ssp can't be correct.
>
> I think it would be better to have less special cases in the FPU.

Agreed,

> I'm not sure
> what you mean by "correct". As above, it gets zeroed in fpu_clone(). I guess you
> want it to be something else.

Well. I think that if copy_thread() path allocate the shadow stack, then
ssp_get() should report the value returned by shstk_alloc_thread_stack().
If the thread runs without shstk/ARCH_SHSTK_SHSTK ssp_get() should return
-ENODEV. Regardless of PF_USER_WORKER.

Now lets recall that my actual motivation is "don't abuse x86_task_fpu(PF_USER_WORKER)",
and we also have ssp_set(). Without this patch which clears ARCH_SHSTK_SHSTK
ssp_set() -> x86_task_fpu(PF_USER_WORKER) has to return a "real" FPU state.

Oleg.