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

Message-ID: <084b7506-028a-4213-8523-57610b498837@intel.com>
Date: Wed, 13 Aug 2025 18:00:22 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Oleg Nesterov <oleg@...hat.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>, Jens Axboe
	<axboe@...nel.dk>
Subject: Re: [PATCH v3 2/2] x86/fpu: Update the debug flow for x86_task_fpu()

On 8/12/2025 5:57 AM, Oleg Nesterov wrote:

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

Thanks for checking.

> 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. 

Having x86_task_fpu() to be consistent would definitely reduce the
number of corner cases we have to deal with :)

"struct fpu" seems to hold some metadata such as avx512_timestamp as
well as some permissions. Hopefully we never need any of that for
PF_USER_WORKERs.

Is the eventual goal of running without "struct fpu" to save memory or
having a cleaner implementation?

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

Agreed, this requires immediate solving.

> 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.
> 

Yeah, using init_fpstate seems reasonable. I don't know what userspace
would do with that information though. But, not returning anything would
likely break some debugging flows.

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

This would modify legacy behavior, but I don't think changing the
register values would have any effect either, right? Another option is
to silently ignore the set(). Maybe we can go with your approach unless
someone complains.

> What do you think?
> 

My knowledge about the FPU handling is fairly limited. So I don't have a
strong opinion on this. Just curiosity and questions! :)

Sohil