From: Matthew Schwartz <matthew.schwartz@linux.dev>
To: Xin Li <xin@zytor.com>, hpa@zytor.com
Cc: Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Paul Gofman <pgofman@codeweavers.com>,
Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
Shuah Khan <shuah@kernel.org>,
Matthew Schwartz <matthew.schwartz@linux.dev>
Subject: [PATCH 1/2] x86/fred: Reconstruct the #GP context for rejected INT instructions
Date: Thu, 17 Sep 2026 16:09:06 -0700 [thread overview]
Message-ID: <20260917230907.2080792-2-matthew.schwartz@linux.dev> (raw)
In-Reply-To: <20260917230907.2080792-1-matthew.schwartz@linux.dev>
FRED event delivery does not use the IDT, so the gate DPL check that
rejects a user INT n falls to software (Intel FRED specification [1],
section 8.3). fred_intx() rejects the same vectors as IDT delivery, but
reports a zero error code and the IP after the INT. This breaks the
signal ABI. Wine uses the error code to recognize INT 0x2d, so the
changed context turns a handled breakpoint into an access violation in
Elden Ring.
Rewind IP using the instruction length in the augmented SS and
synthesize the IDT selector error code, (vector << 3) | 2. Set RF in the
saved flags, as the CPU does for a #GP fault. Section 5.2.1 defines the
saved vector, instruction length and RF state. The supplied length
handles prefixes without reading user memory. Limit the changes to
already-rejected software interrupts, preserving the accepted INT3, INT4
and enabled INT80 paths and hardware exceptions. With IA32 emulation
disabled, INT 0x80 now reports the same #GP as the DPL 0 gate IDT
installs there. The rewound IP also stops fixup_iopl_exception() from
inspecting the byte after the INT.
Also clear the software event flag. Section 6.2.3 specifies that ERETU
with this flag and TF set traps before executing any user instruction. A
tracer that suppresses SIGSEGV and resumes with TF set expects the next
instruction to run first, as after IRET. The sigreturn path clears the
same flag for this reason in prevent_single_step_upon_eretu().
[1] Intel Flexible Return and Event Delivery (FRED) Specification,
revision 9.0 (346446-009US), sections 5.2.1, 6.2.3 and 8.3.
Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Reported-by: Paul Gofman <pgofman@codeweavers.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15745
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16132
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://cdrdv2.intel.com/v1/dl/getContent/678938 # [1]
---
arch/x86/entry/entry_fred.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c
index fb3594ddf731..854899bfec5d 100644
--- a/arch/x86/entry/entry_fred.c
+++ b/arch/x86/entry/entry_fred.c
@@ -10,6 +10,7 @@
#include <asm/desc.h>
#include <asm/fred.h>
#include <asm/idtentry.h>
+#include <asm/processor-flags.h>
#include <asm/syscall.h>
#include <asm/trapnr.h>
#include <asm/traps.h>
@@ -71,7 +72,15 @@ static noinstr void fred_intx(struct pt_regs *regs)
#endif
default:
- return exc_general_protection(regs, 0);
+ /*
+ * Reconstruct the #GP fault state that IDT delivery would produce.
+ * Clear the software event flag so ERETU with TF set does not trap
+ * before the resumed instruction. See prevent_single_step_upon_eretu().
+ */
+ regs->ip -= regs->fred_ss.insnlen;
+ regs->flags |= X86_EFLAGS_RF;
+ regs->fred_ss.swevent = 0;
+ return exc_general_protection(regs, (regs->fred_ss.vector << 3) | 2);
}
}
--
2.55.0
next prev parent reply other threads:[~2026-09-17 23:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 23:09 [PATCH 0/2] x86/fred: Reconstruct fault state " Matthew Schwartz
2026-09-17 23:09 ` Matthew Schwartz [this message]
2026-09-18 0:07 ` [PATCH 1/2] x86/fred: Reconstruct the #GP context " H. Peter Anvin
2026-09-18 10:33 ` Peter Zijlstra
2026-09-18 10:38 ` [tip: x86/urgent] " tip-bot2 for Matthew Schwartz
2026-09-17 23:09 ` [PATCH 2/2] selftests/x86: Check signal state for rejected software interrupts Matthew Schwartz
2026-09-18 10:38 ` [tip: x86/urgent] " tip-bot2 for Matthew Schwartz
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=20260917230907.2080792-2-matthew.schwartz@linux.dev \
--to=matthew.schwartz@linux.dev \
--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=lionel.g.landwerlin@intel.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pgofman@codeweavers.com \
--cc=shuah@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xin@zytor.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®