linux-kernel - Re: [PATCH v3 2/2] x86/fpu: Update the debug flow for x86_task

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250812125700.GA11290@redhat.com>
Date: Tue, 12 Aug 2025 14:57:01 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Sohil Mehta <sohil.mehta@...el.com>
Cc: "Lai, Yi" <yi1.lai@...ux.intel.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...el.com>,
	Sean Christopherson <seanjc@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Vignesh Balasubramanian <vigbalas@....com>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	"Chang S . Bae" <chang.seok.bae@...el.com>,
	Brian Gerst <brgerst@...il.com>, Eric Biggers <ebiggers@...gle.com>,
	Kees Cook <kees@...nel.org>, Chao Gao <chao.gao@...el.com>,
	Fushuai Wang <wangfushuai@...du.com>, linux-kernel@...r.kernel.org,
	yi1.lai@...el.com
Subject: Re: [PATCH v3 2/2] x86/fpu: Update the debug flow for x86_task_fpu()

On 08/08, Sohil Mehta wrote:
>
> On 8/8/2025 8:11 AM, Oleg Nesterov wrote:
>
> >> However, independent of this warning, can xfpregs_get()->sync_fpstate()
> >> be called in the context of the PF_USER_WORKER thread?
> >
> > Probably not but I need to recheck.
>
> IIUC, if a PF_USER_WORKER thread encounters a fault, coredump could get
> triggered in its context. That could cause the above check in
> sync_fpstate() to pass. Maybe I am missing something?

A PF_USER_WORKER can't initiate the coredump, it blocks all signals except
SIGKILL and SIGSTOP. But this doesn't really matter.

First of all, I think that in the long term kthreads and PF_USER_WORKERs
should run without "struct fpu" attached to task_struct, so x86_task_fpu()
should return NULL regardless of CONFIG_X86_DEBUG_FPU in this case. That
is why I like your patch which adds the PF_USER_WORKER check. But this
needs more work.

So. The problem is that do_coredump() paths or ptrace can abuse
PF_USER_WORKER's FPU state for no reason.

To simplify, lets only discuss REGSET64_FP for now. As for xfpregs_get(),
everything looks simple, but needs some preparatory patches. membuf_write()
and copy_xstate_to_uabi_buf() should use &init_fpstate instead of
x86_task_fpu(target)->fpstate when target->flags & PF_USER_WORKER. This
matches the reality.

But what about xfpregs_set() ? Can it simply return, say, -EPERM ?

What do you think?

Oleg.