All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lai, Yi" <yi1.lai@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	yi1.lai@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: Mon, 23 Mar 2026 13:55:51 +0800	[thread overview]
Message-ID: <acDV51/6Nml3dzOk@ly-workstation> (raw)
In-Reply-To: <568aa6c4-6802-4eb5-b412-e3aa93ed9b29@intel.com>

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);

	/*
	 * 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"
	);

	clearhandler(SIGTRAP);

	return gs_val == 3;
}


  parent reply	other threads:[~2026-03-23  5:55 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 [this message]
2026-03-23 16:39         ` Andrew Cooper
2026-03-24  1:28           ` Lai, Yi
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=acDV51/6Nml3dzOk@ly-workstation \
    --to=yi1.lai@linux.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@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.