Re: [PATCH] x86/fred: Correct speculative safety in fred_extint()

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 06/01/2026 5:06 pm, H. Peter Anvin wrote:
> On January 6, 2026 8:46:41 AM PST, Andrew Cooper <andrew.cooper3@citrix.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.

It's called __builtin_speculation_safe_value() and it's as useful as a
chocolate teapot.  When trying to report code generation bugs against
it, I discovered that GCC's security policy is "erm?  maybe try talking
to SUSE" and LLVM was less developed than that.  I gave up trying to get
it adjusted, and am yet to find a user of it outside of the compiler
selftests.

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

All true, but not really relevant.

The real data being hot still doesn't guarantee that memory prediction
is going to guess the right address to speculatively load.

I'm aware that training the memory predictor is far harder than training
the branch predictor, but it possible, and in this case it renders-moot
the attempt to make a safe-even-under-speculation array index.

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

While true, this works until we need our first mitigation in the FRED
entrypath, and then everything goes to pot.

>
> Note that FRED entry is an architectural speculation barrier.

What are the semantics of this new type of barrier?

We were previously given guarantees that ring changes didn't execute
speculatively, which is good enough for every concern we could think of
at the time.

FRED's behaviour of not even reloading %cs/%ss means that in principle
it could speculate straight through a decode-time #UD/#DB/#CP/etc at
full pelt.  I'm glad to hear that it doesn't.

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

I was wondering about how the nested switch statements would fair.

But, given how much nicer everything else is writing it in C, what about
a decent run with PGO, or some manual __attribute__((hot)) for SYSCALL
(from Userspace) and #PF (from supervisor) to help the compiler out with
the fastpaths?

~Andrew