All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, yi1.lai@intel.com
Cc: 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: Fri, 20 Mar 2026 08:50:54 -0700	[thread overview]
Message-ID: <568aa6c4-6802-4eb5-b412-e3aa93ed9b29@intel.com> (raw)
In-Reply-To: <43f2c5c2-6327-4546-b204-5c66b704042e@citrix.com>

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! :)

  reply	other threads:[~2026-03-20 15:50 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 [this message]
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
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=568aa6c4-6802-4eb5-b412-e3aa93ed9b29@intel.com \
    --to=dave.hansen@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --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.