All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lai, Yi" <yi1.lai@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Lai, Yi" <yi1.lai@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	luto@kernel.org, mingo@redhat.com, shuah@kernel.org,
	tglx@kernel.org, x86@kernel.org
Subject: Re: [PATCH] selftests/x86: Fix sysret_rip assertion failure on FRED systems
Date: Tue, 24 Mar 2026 09:28:02 +0800	[thread overview]
Message-ID: <acHoop4NN9KBSyyK@ly-workstation> (raw)
In-Reply-To: <1ede823e-080e-4283-a018-efd62e0c1579@citrix.com>

On Mon, Mar 23, 2026 at 04:39:58PM +0000, Andrew Cooper wrote:
> On 23/03/2026 5:55 am, Lai, Yi wrote:
> > On Fri, Mar 20, 2026 at 08:50:54AM -0700, Dave Hansen 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! :)
> > Thank you both for the review and suggestions. The behavioral difference
> > between IRET and ERETU is a more robust way to detect FRED activation
> > than checking CPUID.
> >
> > How about the following implementation to add a helper function to
> > determine if FRED is enabled at runtime:
> >
> > static void empty_handler(int sig, siginfo_t *info, void *ctx_void)
> > {
> > }
> >
> > static bool is_fred_enabled(void)
> > {
> > 	unsigned short gs_val;
> >
> > 	sethandler(SIGTRAP, empty_handler, 0);
> 
> What about setting SIG_IGN instead?
> 

I tested setting signal(SIGTRAP, SIG_IGN), but it causes the test to
terminate with a trace/breakpoint trap (core dump) when the 'int3'
instruction initiates the hardware exception. Therefore, I will keep the
empty_handler() implementation to ensure it can safely resume execution.

> >
> > 	/*
> > 	 * Distinguish IDT and FRED mode by loading GS with a non-zero RPL and
> > 	 * triggering an exception:
> > 	 * IDT (IRET) clears RPL bits of NULL selectors.
> > 	 * FRED (ERETU) preserves them.
> > 	 *
> > 	 * If GS is loaded with 3 (Index=0, RPL=3), and we trigger an exception:
> > 	 * Legacy should restore GS as 0.
> > 	 * FRED should preserve GS as 3.
> > 	 */
> > 	asm volatile(
> > 		"mov $3, %%ax\n\t"
> > 		"mov %%ax, %%gs\n\t"
> > 		"int3\n\t"
> > 		"mov %%gs, %%ax\n\t"
> > 		"mov %%ax, %0\n\t"
> > 		: "=r" (gs_val)
> > 		:
> > 		: "ax", "memory"
> > 	);
> 
> asm volatile (
>     "mov %[rpl3], %%gs\n\t"
>     "int3\n\t"
>     "mov %%gs, %[res]"
>     : [res] "=r" (gs_val)
>     : [rpl3] "r" (3));
> 
> No need for any clobbers.  Let the compiler do the hard work for you.
>

Thank you for the improved assembly block and it's indeed cleaner. I
will adopt your suggestion and send out v2.

Regards,
Yi Lai

> ~Andrew

  reply	other threads:[~2026-03-24  1:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20  6:33 [PATCH] selftests/x86: Fix sysret_rip assertion failure on FRED systems Yi Lai
2026-03-20 14:31 ` Dave Hansen
2026-03-20 15:47   ` Andrew Cooper
2026-03-20 15:50     ` Dave Hansen
2026-03-22  6:13       ` Xin Li
2026-03-23  6:06         ` Lai, Yi
2026-03-23 16:19           ` Xin Li
2026-03-23 19:11           ` H. Peter Anvin
2026-03-23 19:17             ` Andrew Cooper
2026-03-23 20:27               ` H. Peter Anvin
2026-03-24 14:08                 ` Andrew Cooper
2026-03-24 14:33                   ` H. Peter Anvin
2026-03-24 14:46                     ` Andrew Cooper
2026-03-24 15:16                       ` H. Peter Anvin
2026-03-22 20:08       ` H. Peter Anvin
2026-03-23  5:55       ` Lai, Yi
2026-03-23 16:39         ` Andrew Cooper
2026-03-24  1:28           ` Lai, Yi [this message]
2026-03-24 11:08 ` David Laight
2026-03-24 14:31   ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acHoop4NN9KBSyyK@ly-workstation \
    --to=yi1.lai@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=shuah@kernel.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=yi1.lai@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.