Re: [PATCH] selftests/x86: Fix sysret_rip assertion failure on FRED systems

["Lai, Yi" <yi1.lai@linux.intel.com>]

On Sat, Mar 21, 2026 at 11:13:29PM -0700, Xin Li wrote:
> 
> 
> > On Mar 20, 2026, at 8:50 AM, Dave Hansen <dave.hansen@intel.com> wrote:
> > 
> > On 3/20/26 08:47, Andrew Cooper wrote:
> >>> First, CPUID doesn't tell you if FRED is in use. Is it even on by
> >>> default yet? There might not be a better way to do this than checking
> >>> CPUID, but checking CPUID is imprecise at best.
> >> A reliable way to distinguish IDT and FRED mode is to:
> >> 
> >> 1) Load $3 into %fs (x86_64) or %gs (i386) (i.e. whichever isn't thread
> >> local stoage)
> >> 2) execute a breakpoint, ignore the signal
> >> 3) Look to see whether %fs/%gs holds 3 or 0
> >> 
> >> IRET has a fun behaviour where it zeroes NULL selectors even if they had
> >> a non-zero RPL.
> >> 
> >> ERETU doesn't do this; Andy Luto and I asked for this minor information
> >> leak to be removed, and Intel agreed as it served no purpose anyone
> >> could identify.
> >> 
> >> As a consequence, you can use it to determine whether the kernel used
> >> IRET or ERET to return back to userspace.
> > 
> > I was thinking of just grepping /proc/cpuinfo for "fred", but that
> > sounds much more fun! :)
> 
> +1 :)
> 
> This serves as a key architectural differentiator between FRED and the legacy
> IDT framework.
> 
> For additional context, here is a fix to user segment selector values:
> https://lore.kernel.org/all/174069328263.10177.6796873487608898067.tip-bot2@tip-bot2/
> 
> It’s worth noting that there was an attempt to fix this bug roughly three years
> ago:
> https://lore.kernel.org/lkml/20230220030959.119222-1-ammarfaizi2@gnuweeb.org/
>

Thanks for the context and links, Xin.

My patch is a simple, focused fix to unblock current regression in
'sysret_rip'. The goal is just to ensure it doesn't falsely fail on FRED
systems by skipping the IDT assertion (R11==RFLAGS). 

Checking Ammar's patch series, it indeed looks like a more comprehensive
solution that not only handles the difference but also adds specific
test coverage for consistency. Is there a specific reason it didn't
land in the mainline kernel? If you think that is the preferred
direction, I would be happy to contribute to that effort
collaboratively.


> 
> 
>