linux-kernel - Re: [PATCH 1/2] Documentation: clarify PR_SPEC_L1D

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: <DDJLS7DZYDFW.XKPRC42PXW8I@google.com>
Date: Thu, 16 Oct 2025 08:28:22 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>, Kees Cook <kees@...nel.org>
Cc: Brendan Jackman <jackmanb@...gle.com>, Jonathan Corbet <corbet@....net>, 
	Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, 
	Peter Zijlstra <peterz@...radead.org>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, 
	Balbir Singh <sblbir@...zon.com>, <linux-doc@...r.kernel.org>, 
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] Documentation: clarify PR_SPEC_L1D_FLUSH

On Wed Oct 15, 2025 at 11:42 PM UTC, Josh Poimboeuf wrote:
> On Wed, Oct 15, 2025 at 02:41:18PM -0700, Kees Cook wrote:
>> On Wed, Oct 15, 2025 at 05:02:05PM +0000, Brendan Jackman wrote:
>> > For PR_SPEC_STORE_BYPASS and PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE
>> > means "disable the speculation bug" i.e. "enable the mitigation".
>> > 
>> > For PR_SPEC_L1D_FLUSH, PR_SPEC_DISABLE means "disable the mitigation".
>> > This is not obvious, so document it.
>> 
>> The only thing I can find in Debian Code Search that actually uses
>> PR_SPEC_L1D_FLUSH is stress-ng, and it literally just toggles it before
>> restoring it:
>> https://sources.debian.org/src/stress-ng/0.19.05-1/stress-prctl.c?hl=893#L893
>> 
>> I wonder if we should just fix the prctl to match the existing
>> behaviors?
>
> This feature has existed for almost 5 years, I don't think we can just
> reverse the functionality like that?  There could be proprietary users
> out there (e.g., cloud companies).

Yeah I'm with Josh on this one. I would guess these 3 situations are
about equally likely:

1. Nobody uses this flag for security.

2. People use it, and they are not getting the security properties they
   expect.

3. People do, but they know the meaning of the flag because either they
   read the kernel code (in my experience at Google it's pretty typical
   for security analysts to do this, they are smart and rigorous) or got
   suspicious performance numbers (I've also seen this at Google, IIRC
   this was how we found out about a bug in the Retbleed mitigations).
   Or, it could be the users are working on the same principle as the
   author/reviewers of the patch and they expected the current behaviour
   in the first place.

I think we have to privilege the third case here. Changing the behaviour
is gonna be extremely inconvenient for anyone depending on the current
one (if they even find out about it) so I think we'd have to introduce
a new variant of the API or something. That doesn't seem worth it, I
think the chance of anyone actually adopting the new API is pretty low.