linux-kernel - Re: [PATCH] x86/fred: Correct speculative safety in fred

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: <64E26E02-B9E0-43F1-8FAB-6436BDCFDB50@zytor.com>
Date: Tue, 06 Jan 2026 09:06:24 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>,
        Peter Zijlstra <peterz@...radead.org>
CC: LKML <linux-kernel@...r.kernel.org>, Xin Li <xin@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Subject: Re: [PATCH] x86/fred: Correct speculative safety in fred_extint()

On January 6, 2026 8:46:41 AM PST, Andrew Cooper <andrew.cooper3@...rix.com> wrote:
>On 06/01/2026 3:20 pm, Peter Zijlstra wrote:
>> On Tue, Jan 06, 2026 at 01:15:04PM +0000, Andrew Cooper wrote:
>>> This is why we have array_access_nospec() in Xen, so you can't separate the
>>> safety calculation from the array access.
>>>
>>> The observant reader might notice that the result of reading sysvec_table[] is
>>> also subject to memory predictions.  Aren't CPUs wonderful...
>>>
>>> In practice, even having array_index_nospec() part of the array access
>>> expression is no guarantee of avoiding spilling to the stack.  KASAN is liable
>>> to hide a function call behind the scenes, while UBSAN is very good at
>>> inserting it's own unsafe range checks around objects it knows the size of.
>>> Aren't compilers wonderful...
>> Yeah, then again nobody should be running *SAN kernels in production,
>> right ;-)
>
>Aren't distros wonderful...
>
>~Andrew

This would probably be best addressed with an intrinsic. 

That being said, there are a few reasons why this may not matter in the case of FRED specifically. 

Note that this value comes from memory in the first place, *but* it comes from memory just written to the stack and thus is virtually guaranteed to be live in the L1 TLB and cache. Now with PTL about to be released, I'm also actively looking at ways to optimize FRED entry. One way is to precompute certain useful values in the entry path, instead of simply zeroing the GPRs one can extract data that will be needed further on in the data path into the argument registers. 

Note that FRED entry is an architectural speculation barrier.

Furthermore, my measurements so far indicate that doing an early-out on the SYSCALL path is pretty essential. It might even be valuable enough to do in the assembly stub code.