linux-kernel - Re: PF_USER_WORKERs and shadow stack

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: <0e906a8a-5545-484e-9fe3-9be3e07a033a@intel.com>
Date: Wed, 13 Aug 2025 12:21:04 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Borislav Petkov <bp@...en8.de>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Ingo Molnar <mingo@...nel.org>,
 "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
 Thomas Gleixner <tglx@...utronix.de>, Jens Axboe <axboe@...nel.dk>,
 x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: PF_USER_WORKERs and shadow stack

On 8/13/25 12:14, Oleg Nesterov wrote:
> On 08/13, Dave Hansen wrote:
>> On 8/13/25 09:28, Oleg Nesterov wrote:
>>> But it seems that if a features_enabled(ARCH_SHSTK_SHSTK) thread creates a
>>> PF_USER_WORKER thread, shstk_alloc_thread_stack() will allocate the shadow
>>> stack for no reason.
>> Is this costing us anything other than some CPU cycles and 160 bytes of
>> memory for a VMA?
> Well, I guess no, but I do have another reason for "something-like-this" cleanup.
> I am working on other changes which should eliminate x86_task_fpu(PF_USER_WORKER).
> Hopefully I'll send the patches tomorrow. To remind, see
> https://lore.kernel.org/all/20250812125700.GA11290@redhat.com/

Yep, I assumed the efforts were connected.

> So I'd like to ensure that ssp_active() can't return T in ssp_get().
> 
> And... Dave, I understand that it is very easy to criticize someone else's code 😉
> But - if I am right - the current logic doesn't look clean to me. Regardless.

Hey, I'm all for having "clean" code. But if we're going to add
complexity (aka. code) to the kernel, we should know what it's getting
us other than "cleanliness".

BTW, how many PF_USER_WORKER threads _are_ there out there? I wouldn't
have thought that they were prevalent enough to justify much of an
effort here.