On Sat, Mar 21, 2026 at 11:13:29PM -0700, Xin Li wrote: > > > > On Mar 20, 2026, at 8:50 AM, Dave Hansen <[email protected]> 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/[email protected]/ >
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. > > >
