* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
[not found] <CANd6bgL=v+uReoQznRGKunZQApwV5ESHAQn2_MOt-J-=cPkm9g@mail.gmail.com>
@ 2026-08-11 11:50 ` Jürgen Groß
2026-08-12 9:22 ` 李则良
0 siblings, 1 reply; 12+ messages in thread
From: Jürgen Groß @ 2026-08-11 11:50 UTC (permalink / raw)
To: 李则良,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: H. Peter Anvin, Peter Zijlstra, Kees Cook, Nathan Chancellor,
Josh Poimboeuf, linux-kernel
[-- Attachment #1.1.1: Type: text/plain, Size: 2462 bytes --]
On 11.08.26 13:41, 李则良 wrote:
> From cd58bd112a6178593c6bc9c0f9b307d6897ae3d0 Mon Sep 17 00:00:00 2001
> From: Zeliang Li <lizeliang.linux@gmail.com <mailto:lizeliang.linux@gmail.com>>
> Date: Tue, 11 Aug 2026 19:09:09 +0800
> Subject: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call
> instructions
>
> When the kernel is compiled at a non-default optimization level
> (e.g., KCFLAGS=-O1), the compiler may emit call instruction
> patterns that differ from the expected 6-byte sequence
> (opcodes 0xff 0x15 followed by a 32-bit displacement) checked
> by alt_replace_call().
>
> Currently this triggers a BUG() in apply_alternatives(), causing
> an immediate kernel panic during early boot:
>
> kernel BUG at arch/x86/kernel/alternative.c:558!
>
> Instead of crashing, print a warning (once per boot) and preserve
> the original call instruction verbatim. The call will execute as
> compiled, without any alternatives patching applied. This is a
> graceful degradation: the indirect call remains indirect, which is
> functionally correct albeit slower than the direct-call patching
> that was skipped.
>
> No change to normal -O2 builds, where call instructions continue
> to match the expected pattern.
>
> Signed-off-by: Zeliang Li <lizeliang.linux@gmail.com
> <mailto:lizeliang.linux@gmail.com>>
Please don't send patches as HTML mails!
> ---
> arch/x86/kernel/alternative.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 62936a3bde19..0e3903e76b55 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -554,8 +554,15 @@ static unsigned int alt_replace_call(u8 *instr, u8
> *insn_buff, struct alt_instr
> if (a->instrlen != 6 ||
> instr[0] != CALL_RIP_REL_OPCODE ||
> instr[1] != CALL_RIP_REL_MODRM) {
> - pr_err("ALT_FLAG_DIRECT_CALL set for unrecognized indirect call\n");
> - BUG();
> + static bool warned;
> +
> + if (!warned) {
> + warned = true;
> + pr_warn("%s: skipping unrecognized indirect call (instrlen=%d)\n",
> + __func__, a->instrlen);
> + }
You are open coding pr_warn_once() here.
> + memcpy(insn_buff, instr, a->instrlen);
> + return a->instrlen;
And now you are letting an indirect call survive which is not subject to
any cpu bug mitigations.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-11 11:50 ` [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions Jürgen Groß
@ 2026-08-12 9:22 ` 李则良
2026-08-12 11:00 ` Peter Zijlstra
0 siblings, 1 reply; 12+ messages in thread
From: 李则良 @ 2026-08-12 9:22 UTC (permalink / raw)
To: Jürgen Groß
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Peter Zijlstra, Kees Cook, Nathan Chancellor,
Josh Poimboeuf, linux-kernel
From cd58bd112a6178593c6bc9c0f9b307d6897ae3d0 Mon Sep 17 00:00:00 2001
From: Zeliang Li <lizeliang.linux@gmail.com>
Date: Tue, 11 Aug 2026 19:09:09 +0800
Subject: [PATCH v2] x86/alternative: WARN and skip unrecognized indirect call
only for non-O2 builds
When the kernel is compiled at a non-default optimization level
(e.g., KCFLAGS=-O1 or -O0), the compiler may emit call instruction
patterns that differ from the expected 6-byte sequence
(opcodes 0xff 0x15 followed by a 32-bit displacement) checked
by alt_replace_call().
Currently this triggers a BUG() in apply_alternatives(), causing
an immediate kernel panic during early boot.
For official -O2 builds, the BUG() is appropriate and should be
retained, as the kernel only guarantees correct operation at this
optimization level[reference:0].
For non-standard optimization levels used for debugging purposes,
crashing the kernel is too severe. Instead, issue a WARN_ONCE()
and skip patching for this particular site, preserving the original
indirect call.
This approach balances safety for production builds with usability
for developers using non-standard optimization levels.
Signed-off-by: Zeliang Li <zeliang.li@linux@gmail.com>
---
arch/x86/kernel/alternative.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 62936a3bde19..b8c9d0e1f2a3 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -554,8 +554,21 @@ static unsigned int alt_replace_call(u8 *instr,
u8 *insn_buff, struct alt_instr
if (a->instrlen != 6 ||
instr[0] != CALL_RIP_REL_OPCODE ||
instr[1] != CALL_RIP_REL_MODRM) {
- pr_err("ALT_FLAG_DIRECT_CALL set for unrecognized indirect call\n");
- BUG();
+ /*
+ * Unrecognized indirect call pattern. For -O2 builds this is a
+ * fatal error - the kernel only guarantees correct operation at
+ * this optimization level. For non-O2 builds (debugging), skip
+ * patching to avoid a boot-time crash.
+ */
+#ifdef __OPTIMIZE__
+#if __OPTIMIZE__ == 2
+ BUG();
+#endif
+#endif
+ WARN_ONCE(1,
+ "ALT_FLAG_DIRECT_CALL: unrecognized indirect call at %pS (instrlen=%d)\n",
+ instr, a->instrlen);
+ memcpy(insn_buff, instr, a->instrlen);
+ return a->instrlen;
}
Jürgen Groß <jgross@suse.com> 于2026年8月11日周二 19:50写道：
>
> On 11.08.26 13:41, 李则良 wrote:
> > From cd58bd112a6178593c6bc9c0f9b307d6897ae3d0 Mon Sep 17 00:00:00 2001
> > From: Zeliang Li <lizeliang.linux@gmail.com <mailto:lizeliang.linux@gmail.com>>
> > Date: Tue, 11 Aug 2026 19:09:09 +0800
> > Subject: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call
> > instructions
> >
> > When the kernel is compiled at a non-default optimization level
> > (e.g., KCFLAGS=-O1), the compiler may emit call instruction
> > patterns that differ from the expected 6-byte sequence
> > (opcodes 0xff 0x15 followed by a 32-bit displacement) checked
> > by alt_replace_call().
> >
> > Currently this triggers a BUG() in apply_alternatives(), causing
> > an immediate kernel panic during early boot:
> >
> > kernel BUG at arch/x86/kernel/alternative.c:558!
> >
> > Instead of crashing, print a warning (once per boot) and preserve
> > the original call instruction verbatim. The call will execute as
> > compiled, without any alternatives patching applied. This is a
> > graceful degradation: the indirect call remains indirect, which is
> > functionally correct albeit slower than the direct-call patching
> > that was skipped.
> >
> > No change to normal -O2 builds, where call instructions continue
> > to match the expected pattern.
> >
> > Signed-off-by: Zeliang Li <lizeliang.linux@gmail.com
> > <mailto:lizeliang.linux@gmail.com>>
>
> Please don't send patches as HTML mails!
My apologies. I have now configured my Gmail to send plain text by default.
Thank you for pointing this out.
>
> > ---
> > arch/x86/kernel/alternative.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> > index 62936a3bde19..0e3903e76b55 100644
> > --- a/arch/x86/kernel/alternative.c
> > +++ b/arch/x86/kernel/alternative.c
> > @@ -554,8 +554,15 @@ static unsigned int alt_replace_call(u8 *instr, u8
> > *insn_buff, struct alt_instr
> > if (a->instrlen != 6 ||
> > instr[0] != CALL_RIP_REL_OPCODE ||
> > instr[1] != CALL_RIP_REL_MODRM) {
> > - pr_err("ALT_FLAG_DIRECT_CALL set for unrecognized indirect call\n");
> > - BUG();
> > + static bool warned;
> > +
> > + if (!warned) {
> > + warned = true;
> > + pr_warn("%s: skipping unrecognized indirect call (instrlen=%d)\n",
> > + __func__, a->instrlen);
> > + }
>
> You are open coding pr_warn_once() here.
>
> > + memcpy(insn_buff, instr, a->instrlen);
> > + return a->instrlen;
>
> And now you are letting an indirect call survive which is not subject to
> any cpu bug mitigations.
You are absolutely right – this was a serious oversight in my original
patch. Simply preserving the indirect call would bypass retpoline and
other CPU mitigations, which is unacceptable for production kernels.
To address this, I have revised the patch to distinguish between
optimization levels:
- For -O2 builds (the officially supported configuration), the existing
BUG() is retained, as the kernel only guarantees correct operation at
this level.
- For non-standard -O1/-O0 builds (typically used for debugging), we
issue a WARN_ONCE() and skip patching. This avoids a boot-time crash
for developers, while keeping the production (-O2) path fully secure.
This way, the security impact is limited to non-standard builds, which
are outside the official support scope and are already considered
"developer‑only".
>
>
> Juergen
>
--
KISS == Keep it simple,stupid~:-)
http://lizeliang.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-12 9:22 ` 李则良
@ 2026-08-12 11:00 ` Peter Zijlstra
2026-08-12 11:24 ` H. Peter Anvin
2026-08-12 17:14 ` 李则良
0 siblings, 2 replies; 12+ messages in thread
From: Peter Zijlstra @ 2026-08-12 11:00 UTC (permalink / raw)
To: 李则良
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Nathan Chancellor, Josh Poimboeuf,
linux-kernel
On Wed, Aug 12, 2026 at 05:22:14PM +0800, 李则良 wrote:
> From cd58bd112a6178593c6bc9c0f9b307d6897ae3d0 Mon Sep 17 00:00:00 2001
> From: Zeliang Li <lizeliang.linux@gmail.com>
> Date: Tue, 11 Aug 2026 19:09:09 +0800
> Subject: [PATCH v2] x86/alternative: WARN and skip unrecognized indirect call
> only for non-O2 builds
>
> When the kernel is compiled at a non-default optimization level
> (e.g., KCFLAGS=-O1 or -O0), the compiler may emit call instruction
> patterns that differ from the expected 6-byte sequence
> (opcodes 0xff 0x15 followed by a 32-bit displacement) checked
> by alt_replace_call().
I don't think we want to cater for this. But what actual instruction
sequences is it emitting?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-12 11:00 ` Peter Zijlstra
@ 2026-08-12 11:24 ` H. Peter Anvin
2026-08-12 15:30 ` Borislav Petkov
2026-08-12 17:14 ` 李则良
1 sibling, 1 reply; 12+ messages in thread
From: H. Peter Anvin @ 2026-08-12 11:24 UTC (permalink / raw)
To: Peter Zijlstra, 李则良
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kees Cook, Nathan Chancellor, Josh Poimboeuf, linux-kernel
On August 12, 2026 4:00:23 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Wed, Aug 12, 2026 at 05:22:14PM +0800, 李则良 wrote:
>> From cd58bd112a6178593c6bc9c0f9b307d6897ae3d0 Mon Sep 17 00:00:00 2001
>> From: Zeliang Li <lizeliang.linux@gmail.com>
>> Date: Tue, 11 Aug 2026 19:09:09 +0800
>> Subject: [PATCH v2] x86/alternative: WARN and skip unrecognized indirect call
>> only for non-O2 builds
>>
>> When the kernel is compiled at a non-default optimization level
>> (e.g., KCFLAGS=-O1 or -O0), the compiler may emit call instruction
>> patterns that differ from the expected 6-byte sequence
>> (opcodes 0xff 0x15 followed by a 32-bit displacement) checked
>> by alt_replace_call().
>
>I don't think we want to cater for this. But what actual instruction
>sequences is it emitting?
I'm kind of surprised the kernel compiles with -O0 at all; it certainly didn't used to. -Og was created for a reason.
That being said, if it helps someone debug a problem as long as the kernel also screams "bloody murder don't use me in production" it might be useful.
Honestly, thinking about it, an "unsafe_debug=..." or similar kernel command line option might be justified for things like this; by requiring an active user step to enable the unsafe behavior it should make it much harder for something to sneak into production.
-hpa
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-12 11:24 ` H. Peter Anvin
@ 2026-08-12 15:30 ` Borislav Petkov
0 siblings, 0 replies; 12+ messages in thread
From: Borislav Petkov @ 2026-08-12 15:30 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Peter Zijlstra, 李则良, Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Dave Hansen, x86, Kees Cook,
Nathan Chancellor, Josh Poimboeuf, linux-kernel
On Wed, Aug 12, 2026 at 04:24:37AM -0700, H. Peter Anvin wrote:
> >I don't think we want to cater for this. But what actual instruction
> >sequences is it emitting?
>
> I'm kind of surprised the kernel compiles with -O0 at all; it certainly didn't used to. -Og was created for a reason.
I'm with PeterZ on this. If you hack the tree to modify KCFLAGS, then you get
to keep the pieces too.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-12 11:00 ` Peter Zijlstra
2026-08-12 11:24 ` H. Peter Anvin
@ 2026-08-12 17:14 ` 李则良
2026-08-12 19:01 ` H. Peter Anvin
` (2 more replies)
1 sibling, 3 replies; 12+ messages in thread
From: 李则良 @ 2026-08-12 17:14 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Nathan Chancellor, Josh Poimboeuf,
linux-kernel
>
> I don't think we want to cater for this. But what actual instruction
> sequences is it emitting?
This is the scene that triggers the bug, which can be perfectly
reproduced when KCFLAGS=-O1.
[ 0.111827] SMP alternatives: ALT_FLAG_DIRECT_CALL set for
unrecognized indirect call
[ 0.112083] ------------[ cut here ]------------
[ 0.112417] kernel BUG at arch/x86/kernel/alternative.c:558!
[ 0.113080] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[ 0.113424] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
7.2.0-rc7-00016-g3d6d817622b0-dirty #2 PREEMPT(lazy)
[ 0.114077] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
[ 0.114077] RIP: 0010:apply_alternatives+0x3a6/0x540
[ 0.114077] Code: 8d 04 80 89 95 d1 fe ff ff e9 dd fe ff ff 48 c7
c7 f8 88 9d 82 e8 ea 94 0d 00 90 0f 0b 48 c7 c7 50 89 9d 82 e8 db 94
0d 00 90 <0f> 0b 80 7d ce 00 75 0d 41 80 7e 0d 00 0f 84 14 ff ff ff eb
62 48
[ 0.114077] RSP: 0000:ffffffff82c03d60 EFLAGS: 00010246
[ 0.114077] RAX: 0000000000000049 RBX: ffffffff831dae1c RCX: 0000000000000003
[ 0.114077] RDX: 0000000000000000 RSI: ffffffff82d3cd08 RDI: 0000000000000001
[ 0.114077] RBP: ffffffff82c03ea8 R08: 0000000000000000 R09: 205d373238313131
[ 0.114077] R10: 7265746c6120504d R11: 65746c6120504d53 R12: ffffffff831e116c
[ 0.114077] R13: ffffffff82ee2880 R14: ffffffff831dae0e R15: ffffffff831e1f58
[ 0.114077] FS: 0000000000000000(0000) GS:ffff8882f4a18000(0000)
knlGS:0000000000000000
[ 0.114077] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.114077] CR2: ffff88827ffff000 CR3: 0000000002c30001 CR4: 0000000000770ef0
[ 0.114077] PKRU: 55555554
[ 0.114077] Call Trace:
[ 0.114077] <TASK>
[ 0.114077] ? insn_get_sib+0x21/0x80
[ 0.114077] ? early_fixup_exception+0x85/0xa0
[ 0.114077] alternative_instructions+0x76/0x110
[ 0.114077] arch_cpu_finalize_init+0x113/0x170
[ 0.114077] start_kernel+0x794/0x820
[ 0.114077] x86_64_start_reservations+0x28/0x30
[ 0.114077] x86_64_start_kernel+0xdc/0xe0
[ 0.114077] common_startup_64+0x13e/0x158
[ 0.114077] RIP: 1f0f:0x2e66000000000084
[ 0.114077] Code: Unable to access opcode bytes at 0x2e6600000000005a.
[ 0.114077] RSP: 0000:00841f0f2e660000 EFLAGS: 841f0f2e66 ORIG_RAX:
1f0f2e6600000000
[ 0.114077] RAX: 1f0f2e6600000000 RBX: 1f0f2e6600000000 RCX: 2e66000000000084
[ 0.114077] RDX: 0000000000841f0f RSI: 000000841f0f2e66 RDI: 00841f0f2e660000
[ 0.114077] RBP: 00841f0f2e660000 R08: 00841f0f2e660000 R09: 000000841f0f2e66
[ 0.114077] R10: 0000000000841f0f R11: 2e66000000000084 R12: 000000841f0f2e66
[ 0.114077] R13: 0000000000841f0f R14: 2e66000000000084 R15: 1f0f2e6600000000
[ 0.114077] </TASK>
[ 0.114077] Modules linked in:
[ 0.114078] ---[ end trace 0000000000000000 ]---
[ 0.114405] RIP: 0010:apply_alternatives+0x3a6/0x540
[ 0.115078] Code: 8d 04 80 89 95 d1 fe ff ff e9 dd fe ff ff 48 c7
c7 f8 88 9d 82 e8 ea 94 0d 00 90 0f 0b 48 c7 c7 50 89 9d 82 e8 db 94
0d 00 90 <0f> 0b 80 7d ce 00 75 0d 41 80 7e 0d 00 0f 84 14 ff ff ff eb
62 48
[ 0.116078] RSP: 0000:ffffffff82c03d60 EFLAGS: 00010246
[ 0.116456] RAX: 0000000000000049 RBX: ffffffff831dae1c RCX: 0000000000000003
[ 0.117077] RDX: 0000000000000000 RSI: ffffffff82d3cd08 RDI: 0000000000000001
[ 0.117589] RBP: ffffffff82c03ea8 R08: 0000000000000000 R09: 205d373238313131
[ 0.118077] R10: 7265746c6120504d R11: 65746c6120504d53 R12: ffffffff831e116c
[ 0.118585] R13: ffffffff82ee2880 R14: ffffffff831dae0e R15: ffffffff831e1f58
[ 0.119077] FS: 0000000000000000(0000) GS:ffff8882f4a18000(0000)
knlGS:0000000000000000
[ 0.119642] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.120077] CR2: ffff88827ffff000 CR3: 0000000002c30001 CR4: 0000000000770ef0
[ 0.120537] PKRU: 55555554
[ 0.121078] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.121545] ---[ end Kernel panic - not syncing: Attempted to kill
the idle task! ]---
--
KISS == Keep it simple,stupid~:-)
http://lizeliang.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-12 17:14 ` 李则良
@ 2026-08-12 19:01 ` H. Peter Anvin
2026-08-12 19:02 ` H. Peter Anvin
2026-08-13 9:51 ` Peter Zijlstra
2 siblings, 0 replies; 12+ messages in thread
From: H. Peter Anvin @ 2026-08-12 19:01 UTC (permalink / raw)
To: 李则良, Peter Zijlstra
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kees Cook, Nathan Chancellor, Josh Poimboeuf, linux-kernel
On August 12, 2026 10:14:41 AM PDT, "李则良" <lizeliang.linux@gmail.com> wrote:
>>
>> I don't think we want to cater for this. But what actual instruction
>> sequences is it emitting?
>
>This is the scene that triggers the bug, which can be perfectly
>reproduced when KCFLAGS=-O1.
>
>[ 0.111827] SMP alternatives: ALT_FLAG_DIRECT_CALL set for
>unrecognized indirect call
>[ 0.112083] ------------[ cut here ]------------
>[ 0.112417] kernel BUG at arch/x86/kernel/alternative.c:558!
>[ 0.113080] Oops: invalid opcode: 0000 [#1] SMP NOPTI
>[ 0.113424] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
>7.2.0-rc7-00016-g3d6d817622b0-dirty #2 PREEMPT(lazy)
>[ 0.114077] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
>BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
>[ 0.114077] RIP: 0010:apply_alternatives+0x3a6/0x540
>[ 0.114077] Code: 8d 04 80 89 95 d1 fe ff ff e9 dd fe ff ff 48 c7
>c7 f8 88 9d 82 e8 ea 94 0d 00 90 0f 0b 48 c7 c7 50 89 9d 82 e8 db 94
>0d 00 90 <0f> 0b 80 7d ce 00 75 0d 41 80 7e 0d 00 0f 84 14 ff ff ff eb
>62 48
>[ 0.114077] RSP: 0000:ffffffff82c03d60 EFLAGS: 00010246
>[ 0.114077] RAX: 0000000000000049 RBX: ffffffff831dae1c RCX: 0000000000000003
>[ 0.114077] RDX: 0000000000000000 RSI: ffffffff82d3cd08 RDI: 0000000000000001
>[ 0.114077] RBP: ffffffff82c03ea8 R08: 0000000000000000 R09: 205d373238313131
>[ 0.114077] R10: 7265746c6120504d R11: 65746c6120504d53 R12: ffffffff831e116c
>[ 0.114077] R13: ffffffff82ee2880 R14: ffffffff831dae0e R15: ffffffff831e1f58
>[ 0.114077] FS: 0000000000000000(0000) GS:ffff8882f4a18000(0000)
>knlGS:0000000000000000
>[ 0.114077] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 0.114077] CR2: ffff88827ffff000 CR3: 0000000002c30001 CR4: 0000000000770ef0
>[ 0.114077] PKRU: 55555554
>[ 0.114077] Call Trace:
>[ 0.114077] <TASK>
>[ 0.114077] ? insn_get_sib+0x21/0x80
>[ 0.114077] ? early_fixup_exception+0x85/0xa0
>[ 0.114077] alternative_instructions+0x76/0x110
>[ 0.114077] arch_cpu_finalize_init+0x113/0x170
>[ 0.114077] start_kernel+0x794/0x820
>[ 0.114077] x86_64_start_reservations+0x28/0x30
>[ 0.114077] x86_64_start_kernel+0xdc/0xe0
>[ 0.114077] common_startup_64+0x13e/0x158
>[ 0.114077] RIP: 1f0f:0x2e66000000000084
>[ 0.114077] Code: Unable to access opcode bytes at 0x2e6600000000005a.
>[ 0.114077] RSP: 0000:00841f0f2e660000 EFLAGS: 841f0f2e66 ORIG_RAX:
>1f0f2e6600000000
>[ 0.114077] RAX: 1f0f2e6600000000 RBX: 1f0f2e6600000000 RCX: 2e66000000000084
>[ 0.114077] RDX: 0000000000841f0f RSI: 000000841f0f2e66 RDI: 00841f0f2e660000
>[ 0.114077] RBP: 00841f0f2e660000 R08: 00841f0f2e660000 R09: 000000841f0f2e66
>[ 0.114077] R10: 0000000000841f0f R11: 2e66000000000084 R12: 000000841f0f2e66
>[ 0.114077] R13: 0000000000841f0f R14: 2e66000000000084 R15: 1f0f2e6600000000
>[ 0.114077] </TASK>
>[ 0.114077] Modules linked in:
>[ 0.114078] ---[ end trace 0000000000000000 ]---
>[ 0.114405] RIP: 0010:apply_alternatives+0x3a6/0x540
>[ 0.115078] Code: 8d 04 80 89 95 d1 fe ff ff e9 dd fe ff ff 48 c7
>c7 f8 88 9d 82 e8 ea 94 0d 00 90 0f 0b 48 c7 c7 50 89 9d 82 e8 db 94
>0d 00 90 <0f> 0b 80 7d ce 00 75 0d 41 80 7e 0d 00 0f 84 14 ff ff ff eb
>62 48
>[ 0.116078] RSP: 0000:ffffffff82c03d60 EFLAGS: 00010246
>[ 0.116456] RAX: 0000000000000049 RBX: ffffffff831dae1c RCX: 0000000000000003
>[ 0.117077] RDX: 0000000000000000 RSI: ffffffff82d3cd08 RDI: 0000000000000001
>[ 0.117589] RBP: ffffffff82c03ea8 R08: 0000000000000000 R09: 205d373238313131
>[ 0.118077] R10: 7265746c6120504d R11: 65746c6120504d53 R12: ffffffff831e116c
>[ 0.118585] R13: ffffffff82ee2880 R14: ffffffff831dae0e R15: ffffffff831e1f58
>[ 0.119077] FS: 0000000000000000(0000) GS:ffff8882f4a18000(0000)
>knlGS:0000000000000000
>[ 0.119642] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 0.120077] CR2: ffff88827ffff000 CR3: 0000000002c30001 CR4: 0000000000770ef0
>[ 0.120537] PKRU: 55555554
>[ 0.121078] Kernel panic - not syncing: Attempted to kill the idle task!
>[ 0.121545] ---[ end Kernel panic - not syncing: Attempted to kill
>the idle task! ]---
>
Well, what about -Og?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-12 17:14 ` 李则良
2026-08-12 19:01 ` H. Peter Anvin
@ 2026-08-12 19:02 ` H. Peter Anvin
2026-08-13 9:51 ` Peter Zijlstra
2 siblings, 0 replies; 12+ messages in thread
From: H. Peter Anvin @ 2026-08-12 19:02 UTC (permalink / raw)
To: 李则良, Peter Zijlstra
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kees Cook, Nathan Chancellor, Josh Poimboeuf, linux-kernel
On August 12, 2026 10:14:41 AM PDT, "李则良" <lizeliang.linux@gmail.com> wrote:
>>
>> I don't think we want to cater for this. But what actual instruction
>> sequences is it emitting?
>
>This is the scene that triggers the bug, which can be perfectly
>reproduced when KCFLAGS=-O1.
>
>[ 0.111827] SMP alternatives: ALT_FLAG_DIRECT_CALL set for
>unrecognized indirect call
>[ 0.112083] ------------[ cut here ]------------
>[ 0.112417] kernel BUG at arch/x86/kernel/alternative.c:558!
>[ 0.113080] Oops: invalid opcode: 0000 [#1] SMP NOPTI
>[ 0.113424] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
>7.2.0-rc7-00016-g3d6d817622b0-dirty #2 PREEMPT(lazy)
>[ 0.114077] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
>BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
>[ 0.114077] RIP: 0010:apply_alternatives+0x3a6/0x540
>[ 0.114077] Code: 8d 04 80 89 95 d1 fe ff ff e9 dd fe ff ff 48 c7
>c7 f8 88 9d 82 e8 ea 94 0d 00 90 0f 0b 48 c7 c7 50 89 9d 82 e8 db 94
>0d 00 90 <0f> 0b 80 7d ce 00 75 0d 41 80 7e 0d 00 0f 84 14 ff ff ff eb
>62 48
>[ 0.114077] RSP: 0000:ffffffff82c03d60 EFLAGS: 00010246
>[ 0.114077] RAX: 0000000000000049 RBX: ffffffff831dae1c RCX: 0000000000000003
>[ 0.114077] RDX: 0000000000000000 RSI: ffffffff82d3cd08 RDI: 0000000000000001
>[ 0.114077] RBP: ffffffff82c03ea8 R08: 0000000000000000 R09: 205d373238313131
>[ 0.114077] R10: 7265746c6120504d R11: 65746c6120504d53 R12: ffffffff831e116c
>[ 0.114077] R13: ffffffff82ee2880 R14: ffffffff831dae0e R15: ffffffff831e1f58
>[ 0.114077] FS: 0000000000000000(0000) GS:ffff8882f4a18000(0000)
>knlGS:0000000000000000
>[ 0.114077] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 0.114077] CR2: ffff88827ffff000 CR3: 0000000002c30001 CR4: 0000000000770ef0
>[ 0.114077] PKRU: 55555554
>[ 0.114077] Call Trace:
>[ 0.114077] <TASK>
>[ 0.114077] ? insn_get_sib+0x21/0x80
>[ 0.114077] ? early_fixup_exception+0x85/0xa0
>[ 0.114077] alternative_instructions+0x76/0x110
>[ 0.114077] arch_cpu_finalize_init+0x113/0x170
>[ 0.114077] start_kernel+0x794/0x820
>[ 0.114077] x86_64_start_reservations+0x28/0x30
>[ 0.114077] x86_64_start_kernel+0xdc/0xe0
>[ 0.114077] common_startup_64+0x13e/0x158
>[ 0.114077] RIP: 1f0f:0x2e66000000000084
>[ 0.114077] Code: Unable to access opcode bytes at 0x2e6600000000005a.
>[ 0.114077] RSP: 0000:00841f0f2e660000 EFLAGS: 841f0f2e66 ORIG_RAX:
>1f0f2e6600000000
>[ 0.114077] RAX: 1f0f2e6600000000 RBX: 1f0f2e6600000000 RCX: 2e66000000000084
>[ 0.114077] RDX: 0000000000841f0f RSI: 000000841f0f2e66 RDI: 00841f0f2e660000
>[ 0.114077] RBP: 00841f0f2e660000 R08: 00841f0f2e660000 R09: 000000841f0f2e66
>[ 0.114077] R10: 0000000000841f0f R11: 2e66000000000084 R12: 000000841f0f2e66
>[ 0.114077] R13: 0000000000841f0f R14: 2e66000000000084 R15: 1f0f2e6600000000
>[ 0.114077] </TASK>
>[ 0.114077] Modules linked in:
>[ 0.114078] ---[ end trace 0000000000000000 ]---
>[ 0.114405] RIP: 0010:apply_alternatives+0x3a6/0x540
>[ 0.115078] Code: 8d 04 80 89 95 d1 fe ff ff e9 dd fe ff ff 48 c7
>c7 f8 88 9d 82 e8 ea 94 0d 00 90 0f 0b 48 c7 c7 50 89 9d 82 e8 db 94
>0d 00 90 <0f> 0b 80 7d ce 00 75 0d 41 80 7e 0d 00 0f 84 14 ff ff ff eb
>62 48
>[ 0.116078] RSP: 0000:ffffffff82c03d60 EFLAGS: 00010246
>[ 0.116456] RAX: 0000000000000049 RBX: ffffffff831dae1c RCX: 0000000000000003
>[ 0.117077] RDX: 0000000000000000 RSI: ffffffff82d3cd08 RDI: 0000000000000001
>[ 0.117589] RBP: ffffffff82c03ea8 R08: 0000000000000000 R09: 205d373238313131
>[ 0.118077] R10: 7265746c6120504d R11: 65746c6120504d53 R12: ffffffff831e116c
>[ 0.118585] R13: ffffffff82ee2880 R14: ffffffff831dae0e R15: ffffffff831e1f58
>[ 0.119077] FS: 0000000000000000(0000) GS:ffff8882f4a18000(0000)
>knlGS:0000000000000000
>[ 0.119642] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 0.120077] CR2: ffff88827ffff000 CR3: 0000000002c30001 CR4: 0000000000770ef0
>[ 0.120537] PKRU: 55555554
>[ 0.121078] Kernel panic - not syncing: Attempted to kill the idle task!
>[ 0.121545] ---[ end Kernel panic - not syncing: Attempted to kill
>the idle task! ]---
>
That a UD2 opcode...
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-12 17:14 ` 李则良
2026-08-12 19:01 ` H. Peter Anvin
2026-08-12 19:02 ` H. Peter Anvin
@ 2026-08-13 9:51 ` Peter Zijlstra
2026-08-13 19:35 ` 李则良
2 siblings, 1 reply; 12+ messages in thread
From: Peter Zijlstra @ 2026-08-13 9:51 UTC (permalink / raw)
To: 李则良
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Nathan Chancellor, Josh Poimboeuf,
linux-kernel
On Thu, Aug 13, 2026 at 01:14:41AM +0800, 李则良 wrote:
> >
> > I don't think we want to cater for this. But what actual instruction
> > sequences is it emitting?
>
> This is the scene that triggers the bug, which can be perfectly
> reproduced when KCFLAGS=-O1.
>
That's not what I asked, now was it. I asked what opcodes it does
generate. Disassemble an affected function and show the difference
between the normal -O2 and your -O1 build that causes the failure.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-13 9:51 ` Peter Zijlstra
@ 2026-08-13 19:35 ` 李则良
2026-08-13 19:57 ` 李则良
0 siblings, 1 reply; 12+ messages in thread
From: 李则良 @ 2026-08-13 19:35 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Nathan Chancellor, Josh Poimboeuf,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3290 bytes --]
>
> That's not what I asked, now was it. I asked what opcodes it does
> generate. Disassemble an affected function and show the difference
> between the normal -O2 and your -O1 build that causes the failure.
on vmlinux-O1:
(gdb) until arch/x86/kernel/alternative.c:557
alt_replace_call (instr=0xffffffff82f447e5 <early_fixup_exception+133>
"\377S\b\220\220\353\371[A\\]\303\314\314\314\314\303\314\314\314\314f\017\037D",
insn_buff=0xffffffff82c03d78 <init_thread_union+15736>
"\350\263\177\020\377",
a=0xffffffff831dae0e) at arch/x86/kernel/alternative.c:557
557 pr_err("ALT_FLAG_DIRECT_CALL set for unrecognized indirect call\n");
vmlinux-O1:
0xffffffff82f447e5 <+133>: ff 53 08 call QWORD PTR [rbx+0x8]
0xffffffff82f447e8 <+136>: 90 nop
0xffffffff82f447e9 <+137>: 90 nop
0xffffffff82f447ea <+138>: eb f9 jmp
0xffffffff82f447e5 <early_fixup_exception+133>
0xffffffff82f447ec <+140>: 5b pop rbx
0xffffffff82f447ed <+141>: 41 5c pop r12
vmlinux-O2:
0xffffffff82f3bf4b <+123>: 74 b0 je
0xffffffff82f3befd <early_fixup_exception+45>
0xffffffff82f3bf4d <+125>: eb 08 jmp
0xffffffff82f3bf57 <early_fixup_exception+135>
0xffffffff82f3bf4f <+127>: ff 15 33 32 d0 ff call QWORD PTR
[rip+0xffffffffffd03233] # 0xffffffff82c3f188 <pv_ops+8>
0xffffffff82f3bf55 <+133>: eb f8 jmp
0xffffffff82f3bf4f <early_fixup_exception+127>
0xffffffff82f3bf57 <+135>: 5b pop rbx
0xffffffff82f3bf58 <+136>: 41 5c pop r12
0xffffffff82f3bf5a <+138>: 5d pop rbp
I use the patch below to bypass the problem while keeping all logic of
alt_replace_call intact.
From 2538684697e537298aa9082b582bc7dddd29b278 Mon Sep 17 00:00:00 2001
From: Zeliang Li <lizeliang.linux@gmail.com>
Date: Fri, 14 Aug 2026 02:32:19 +0800
Subject: [PATCH] x86/mm: force O2 optimization for early_fixup_exception
When the kernel is compiled with non-standard optimization flags
(e.g., KCFLAGS=-O1), the function early_fixup_exception may be
compiled to an indirect call instruction that is not recognized
by alt_replace_call() (e.g., "call *0x8(%rbx)"). This triggers a
BUG() during early boot, as seen in:
ALT_FLAG_DIRECT_CALL: original instruction is not a 6-byte ...
instruction at early_fixup_exception+0x85/0xa0, length=5
instruction bytes: ff 53 08 90 90
Force this function to be compiled with -O2 optimization level,
which guarantees the standard 6-byte `ff 15 <disp32>` form used
by alternatives patching.
Signed-off-by: Zeliang Li <lizeliang.linux@gmail.com>
---
arch/x86/mm/extable.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index ceb8d03191ab..5d5c7510a817 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -375,6 +375,7 @@ int fixup_exception(struct pt_regs *regs, int
trapnr, unsigned long error_code,
extern unsigned int early_recursion_flag;
/* Restricted version used during very early boot */
+__attribute__((optimize("O2")))
void __init early_fixup_exception(struct pt_regs *regs, int trapnr)
{
/* Ignore early NMIs. */
--
2.53.0
--
KISS == Keep it simple,stupid~:-)
http://lizeliang.org
[-- Attachment #2: O2-gdb --]
[-- Type: application/octet-stream, Size: 3595 bytes --]
(gdb) set disassembly-flavor intel
(gdb) disassemble /r early_fixup_exception
Dump of assembler code for function early_fixup_exception:
0xffffffff82f3bed0 <+0>: f3 0f 1e fa endbr64
0xffffffff82f3bed4 <+4>: 83 fe 02 cmp esi,0x2
0xffffffff82f3bed7 <+7>: 0f 84 83 00 00 00 je 0xffffffff82f3bf60 <early_fixup_exception+144>
0xffffffff82f3bedd <+13>: 55 push rbp
0xffffffff82f3bede <+14>: 48 89 e5 mov rbp,rsp
0xffffffff82f3bee1 <+17>: 41 54 push r12
0xffffffff82f3bee3 <+19>: 53 push rbx
0xffffffff82f3bee4 <+20>: 83 3d 15 61 0a 00 02 cmp DWORD PTR [rip+0xa6115],0x2 # 0xffffffff82fe2000 <early_recursion_flag>
0xffffffff82f3beeb <+27>: 77 62 ja 0xffffffff82f3bf4f <early_fixup_exception+127>
0xffffffff82f3beed <+29>: 41 89 f4 mov r12d,esi
0xffffffff82f3bef0 <+32>: 48 89 fb mov rbx,rdi
0xffffffff82f3bef3 <+35>: 66 83 bf 88 00 00 00 10 cmp WORD PTR [rdi+0x88],0x10
0xffffffff82f3befb <+43>: 74 2f je 0xffffffff82f3bf2c <early_fixup_exception+92>
0xffffffff82f3befd <+45>: 41 0f 20 d1 mov r9,cr2
0xffffffff82f3bf01 <+49>: 48 8b 8b 80 00 00 00 mov rcx,QWORD PTR [rbx+0x80]
0xffffffff82f3bf08 <+56>: 4c 8b 43 78 mov r8,QWORD PTR [rbx+0x78]
0xffffffff82f3bf0c <+60>: 44 89 e6 mov esi,r12d
0xffffffff82f3bf0f <+63>: 48 c7 c7 2c 5a 83 82 mov rdi,0xffffffff82835a2c
0xffffffff82f3bf16 <+70>: 0f b7 93 88 00 00 00 movzx edx,WORD PTR [rbx+0x88]
0xffffffff82f3bf1d <+77>: e8 ae fa 3c fe call 0xffffffff8130b9d0 <early_printk>
0xffffffff82f3bf22 <+82>: 48 89 df mov rdi,rbx
0xffffffff82f3bf25 <+85>: e8 86 c9 30 fe call 0xffffffff812488b0 <show_regs>
0xffffffff82f3bf2a <+90>: eb 23 jmp 0xffffffff82f3bf4f <early_fixup_exception+127>
0xffffffff82f3bf2c <+92>: 48 8b 57 78 mov rdx,QWORD PTR [rdi+0x78]
0xffffffff82f3bf30 <+96>: 31 c9 xor ecx,ecx
0xffffffff82f3bf32 <+98>: e8 39 c9 34 fe call 0xffffffff81288870 <fixup_exception>
0xffffffff82f3bf37 <+103>: 85 c0 test eax,eax
0xffffffff82f3bf39 <+105>: 75 1c jne 0xffffffff82f3bf57 <early_fixup_exception+135>
0xffffffff82f3bf3b <+107>: 41 83 fc 06 cmp r12d,0x6
0xffffffff82f3bf3f <+111>: 75 bc jne 0xffffffff82f3befd <early_fixup_exception+45>
0xffffffff82f3bf41 <+113>: 48 89 df mov rdi,rbx
0xffffffff82f3bf44 <+116>: e8 97 93 10 ff call 0xffffffff820452e0 <handle_bug>
0xffffffff82f3bf49 <+121>: 84 c0 test al,al
0xffffffff82f3bf4b <+123>: 74 b0 je 0xffffffff82f3befd <early_fixup_exception+45>
0xffffffff82f3bf4d <+125>: eb 08 jmp 0xffffffff82f3bf57 <early_fixup_exception+135>
0xffffffff82f3bf4f <+127>: ff 15 33 32 d0 ff call QWORD PTR [rip+0xffffffffffd03233] # 0xffffffff82c3f188 <pv_ops+8>
0xffffffff82f3bf55 <+133>: eb f8 jmp 0xffffffff82f3bf4f <early_fixup_exception+127>
0xffffffff82f3bf57 <+135>: 5b pop rbx
0xffffffff82f3bf58 <+136>: 41 5c pop r12
0xffffffff82f3bf5a <+138>: 5d pop rbp
0xffffffff82f3bf5b <+139>: e9 50 75 11 ff jmp 0xffffffff820534b0 <__x86_return_thunk>
0xffffffff82f3bf60 <+144>: e9 4b 75 11 ff jmp 0xffffffff820534b0 <__x86_return_thunk>
End of assembler dump.
(gdb)
[-- Attachment #3: O1-gdb --]
[-- Type: application/octet-stream, Size: 4327 bytes --]
(gdb) until arch/x86/kernel/alternative.c:557
alt_replace_call (instr=0xffffffff82f447e5 <early_fixup_exception+133> "\377S\b\220\220\353\371[A\\]\303\314\314\314\314\303\314\314\314\314f\017\037D", insn_buff=0xffffffff82c03d78 <init_thread_union+15736> "\350\263\177\020\377",
a=0xffffffff831dae0e) at arch/x86/kernel/alternative.c:557
557 pr_err("ALT_FLAG_DIRECT_CALL set for unrecognized indirect call\n");
(gdb) set disassembly-flavor intel
(gdb) disassemble /r early_fixup_exception
Dump of assembler code for function early_fixup_exception:
0xffffffff82f44760 <+0>: f3 0f 1e fa endbr64
0xffffffff82f44764 <+4>: 83 fe 02 cmp esi,0x2
0xffffffff82f44767 <+7>: 0f 84 88 00 00 00 je 0xffffffff82f447f5 <early_fixup_exception+149>
0xffffffff82f4476d <+13>: 55 push rbp
0xffffffff82f4476e <+14>: 48 89 e5 mov rbp,rsp
0xffffffff82f44771 <+17>: 41 54 push r12
0xffffffff82f44773 <+19>: 53 push rbx
0xffffffff82f44774 <+20>: 48 89 fb mov rbx,rdi
0xffffffff82f44777 <+23>: 41 89 f4 mov r12d,esi
0xffffffff82f4477a <+26>: 83 3d 7f b8 0a 00 02 cmp DWORD PTR [rip+0xab87f],0x2 # 0xffffffff82ff0000 <early_recursion_flag>
0xffffffff82f44781 <+33>: 77 5b ja 0xffffffff82f447de <early_fixup_exception+126>
0xffffffff82f44783 <+35>: 66 83 bf 88 00 00 00 10 cmp WORD PTR [rdi+0x88],0x10
0xffffffff82f4478b <+43>: 75 24 jne 0xffffffff82f447b1 <early_fixup_exception+81>
0xffffffff82f4478d <+45>: 48 8b 57 78 mov rdx,QWORD PTR [rdi+0x78]
0xffffffff82f44791 <+49>: b9 00 00 00 00 mov ecx,0x0
0xffffffff82f44796 <+54>: e8 35 0d 34 fe call 0xffffffff812854d0 <fixup_exception>
0xffffffff82f4479b <+59>: 85 c0 test eax,eax
0xffffffff82f4479d <+61>: 75 4d jne 0xffffffff82f447ec <early_fixup_exception+140>
0xffffffff82f4479f <+63>: 41 83 fc 06 cmp r12d,0x6
0xffffffff82f447a3 <+67>: 75 0c jne 0xffffffff82f447b1 <early_fixup_exception+81>
0xffffffff82f447a5 <+69>: 48 89 df mov rdi,rbx
0xffffffff82f447a8 <+72>: e8 d3 3d 3a ff call 0xffffffff822e8580 <handle_bug>
0xffffffff82f447ad <+77>: 84 c0 test al,al
0xffffffff82f447af <+79>: 75 3b jne 0xffffffff82f447ec <early_fixup_exception+140>
0xffffffff82f447b1 <+81>: 41 0f 20 d1 mov r9,cr2
0xffffffff82f447b5 <+85>: 48 8b 8b 80 00 00 00 mov rcx,QWORD PTR [rbx+0x80]
0xffffffff82f447bc <+92>: 0f b7 93 88 00 00 00 movzx edx,WORD PTR [rbx+0x88]
0xffffffff82f447c3 <+99>: 4c 8b 43 78 mov r8,QWORD PTR [rbx+0x78]
0xffffffff82f447c7 <+103>: 44 89 e6 mov esi,r12d
0xffffffff82f447ca <+106>: 48 c7 c7 08 32 9e 82 mov rdi,0xffffffff829e3208
0xffffffff82f447d1 <+113>: e8 ba a0 3d fe call 0xffffffff8131e890 <early_printk>
0xffffffff82f447d6 <+118>: 48 89 df mov rdi,rbx
0xffffffff82f447d9 <+121>: e8 82 73 2f fe call 0xffffffff8123bb60 <show_regs>
0xffffffff82f447de <+126>: 48 c7 c3 80 f1 c3 82 mov rbx,0xffffffff82c3f180
0xffffffff82f447e5 <+133>: ff 53 08 call QWORD PTR [rbx+0x8]
0xffffffff82f447e8 <+136>: 90 nop
0xffffffff82f447e9 <+137>: 90 nop
0xffffffff82f447ea <+138>: eb f9 jmp 0xffffffff82f447e5 <early_fixup_exception+133>
0xffffffff82f447ec <+140>: 5b pop rbx
0xffffffff82f447ed <+141>: 41 5c pop r12
0xffffffff82f447ef <+143>: 5d pop rbp
0xffffffff82f447f0 <+144>: c3 ret
0xffffffff82f447f1 <+145>: cc int3
0xffffffff82f447f2 <+146>: cc int3
--Type <RET> for more, q to quit, c to continue without paging--
0xffffffff82f447f3 <+147>: cc int3
0xffffffff82f447f4 <+148>: cc int3
0xffffffff82f447f5 <+149>: c3 ret
0xffffffff82f447f6 <+150>: cc int3
0xffffffff82f447f7 <+151>: cc int3
0xffffffff82f447f8 <+152>: cc int3
0xffffffff82f447f9 <+153>: cc int3
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-13 19:35 ` 李则良
@ 2026-08-13 19:57 ` 李则良
2026-08-14 10:15 ` Jürgen Groß
0 siblings, 1 reply; 12+ messages in thread
From: 李则良 @ 2026-08-13 19:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jürgen Groß,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Nathan Chancellor, Josh Poimboeuf,
linux-kernel
I am currently testing the more general approach shown below. Your
review is also appreciated.
on vmlinux-O1:
0xffffffff82f447de <+126>: ff 15 a4 a9 cf ff call QWORD PTR
[rip+0xffffffffffcfa9a4] # 0xffffffff82c3f188 <pv_ops+8>
0xffffffff82f447e4 <+132>: eb f8 jmp
0xffffffff82f447de <early_fixup_exception+126>
0xffffffff82f447e6 <+134>: 5b pop rbx
0xffffffff82f447e7 <+135>: 41 5c pop r12
0xffffffff82f447e9 <+137>: 5d pop rbp
on vmlinux-O2:
0xffffffff82f3bf4f <+127>: ff 15 33 32 d0 ff call QWORD PTR
[rip+0xffffffffffd03233] # 0xffffffff82c3f188 <pv_ops+8>
0xffffffff82f3bf55 <+133>: eb f8 jmp
0xffffffff82f3bf4f <early_fixup_exception+127>
0xffffffff82f3bf57 <+135>: 5b pop rbx
0xffffffff82f3bf58 <+136>: 41 5c pop r12
0xffffffff82f3bf5a <+138>: 5d pop rbp
This is an early draft – please review. Thanks in advance.
From 5989dcf448e4d23ea4f3a0f91fec34f3dd25d26c Mon Sep 17 00:00:00 2001
From: Zeliang Li <lizeliang.linux@gmail.com>
Date: Fri, 14 Aug 2026 03:17:38 +0800
Subject: [PATCH] x86/paravirt: Force RIP-relative paravirt calls under low
optimization levels
When compiling the kernel with non-standard lower optimization levels like
-O1 (e.g., during specific debugging or framework testing setups) using
newer toolchains like GCC 15.2.0, the compiler exhibits passive register
hoisting. In complex code paths like early_fixup_exception(), it caches the
base address of the global 'pv_ops' structure into a general-purpose register
instead of issuing direct RIP-relative memory loads, producing:
mov $0xffffffff82c3f180, %rbx
call *0x8(%rbx)
While this behavior is bypassed under aggressive -O2 optimizations, under -O1
it leaves a register-relative indirect call. This violates the strict format
assertion in the x86 alternative text-patching engine (alt_replace_call),
which expects an 'ALT_FLAG_DIRECT_CALL' site to be a standard 6-byte
RIP-relative indirect call (ff 15), leading to a boot-time kernel BUG.
Fix this by changing the x86_64 paravirt inline assembly to use an "i"
(immediate) constraint for the function pointer address, and explicitly
reference it via (%rip) in the assembly template. This removes the
toolchain's ability to select any other addressing mode, guaranteeing the
emission of compliant 'call *pv_ops+offset(%rip)' sequences on x86_64
regardless of the active compiler -O flag.
For i386, the original "m" constraint is retained since RIP-relative
addressing does not exist on 32-bit x86.
Signed-off-by: Zeliang Li <lizeliang.linux@gmail.com>
---
arch/x86/include/asm/paravirt_types.h | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index b4c4a23e77a1..e8047bdbed3a 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -184,8 +184,6 @@ struct paravirt_patch_template {
extern struct paravirt_patch_template pv_ops;
-#define paravirt_ptr(array, op) [paravirt_opptr] "m" (array.op)
-
/*
* This generates an indirect call based on the operation type number.
*
@@ -197,9 +195,20 @@ extern struct paravirt_patch_template pv_ops;
* OTOH since this is effectively a __nocfi indirect call, the paravirt stubs
* don't need to bother with CFI prefixes.
*/
+#ifdef CONFIG_X86_64
+
+#define paravirt_ptr(array, op) [paravirt_opptr] "i" (&(array.op))
#define PARAVIRT_CALL \
ANNOTATE_RETPOLINE_SAFE "\n\t" \
- "call *%[paravirt_opptr]"
+ "call *%c[paravirt_opptr](%%rip);"
+#else /* CONFIG_X86_32 */
+
+#define paravirt_ptr(array, op) [paravirt_opptr] "m" (array.op)
+#define PARAVIRT_CALL \
+ ANNOTATE_RETPOLINE_SAFE "\n\t" \
+ "call *%[paravirt_opptr];"
+
+#endif /* CONFIG_X86_64 */
/*
* These macros are intended to wrap calls through one of the paravirt
--
2.53.0
李则良 <lizeliang.linux@gmail.com> 于2026年8月14日周五 03:35写道：
>
> >
> > That's not what I asked, now was it. I asked what opcodes it does
> > generate. Disassemble an affected function and show the difference
> > between the normal -O2 and your -O1 build that causes the failure.
> on vmlinux-O1:
> (gdb) until arch/x86/kernel/alternative.c:557
> alt_replace_call (instr=0xffffffff82f447e5 <early_fixup_exception+133>
> "\377S\b\220\220\353\371[A\\]\303\314\314\314\314\303\314\314\314\314f\017\037D",
> insn_buff=0xffffffff82c03d78 <init_thread_union+15736>
> "\350\263\177\020\377",
> a=0xffffffff831dae0e) at arch/x86/kernel/alternative.c:557
> 557 pr_err("ALT_FLAG_DIRECT_CALL set for unrecognized indirect call\n");
> vmlinux-O1:
> 0xffffffff82f447e5 <+133>: ff 53 08 call QWORD PTR [rbx+0x8]
> 0xffffffff82f447e8 <+136>: 90 nop
> 0xffffffff82f447e9 <+137>: 90 nop
> 0xffffffff82f447ea <+138>: eb f9 jmp
> 0xffffffff82f447e5 <early_fixup_exception+133>
> 0xffffffff82f447ec <+140>: 5b pop rbx
> 0xffffffff82f447ed <+141>: 41 5c pop r12
>
> vmlinux-O2:
> 0xffffffff82f3bf4b <+123>: 74 b0 je
> 0xffffffff82f3befd <early_fixup_exception+45>
> 0xffffffff82f3bf4d <+125>: eb 08 jmp
> 0xffffffff82f3bf57 <early_fixup_exception+135>
> 0xffffffff82f3bf4f <+127>: ff 15 33 32 d0 ff call QWORD PTR
> [rip+0xffffffffffd03233] # 0xffffffff82c3f188 <pv_ops+8>
> 0xffffffff82f3bf55 <+133>: eb f8 jmp
> 0xffffffff82f3bf4f <early_fixup_exception+127>
> 0xffffffff82f3bf57 <+135>: 5b pop rbx
> 0xffffffff82f3bf58 <+136>: 41 5c pop r12
> 0xffffffff82f3bf5a <+138>: 5d pop rbp
>
> I use the patch below to bypass the problem while keeping all logic of
> alt_replace_call intact.
>
> From 2538684697e537298aa9082b582bc7dddd29b278 Mon Sep 17 00:00:00 2001
> From: Zeliang Li <lizeliang.linux@gmail.com>
> Date: Fri, 14 Aug 2026 02:32:19 +0800
> Subject: [PATCH] x86/mm: force O2 optimization for early_fixup_exception
>
> When the kernel is compiled with non-standard optimization flags
> (e.g., KCFLAGS=-O1), the function early_fixup_exception may be
> compiled to an indirect call instruction that is not recognized
> by alt_replace_call() (e.g., "call *0x8(%rbx)"). This triggers a
> BUG() during early boot, as seen in:
>
> ALT_FLAG_DIRECT_CALL: original instruction is not a 6-byte ...
> instruction at early_fixup_exception+0x85/0xa0, length=5
> instruction bytes: ff 53 08 90 90
>
> Force this function to be compiled with -O2 optimization level,
> which guarantees the standard 6-byte `ff 15 <disp32>` form used
> by alternatives patching.
>
> Signed-off-by: Zeliang Li <lizeliang.linux@gmail.com>
> ---
> arch/x86/mm/extable.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
> index ceb8d03191ab..5d5c7510a817 100644
> --- a/arch/x86/mm/extable.c
> +++ b/arch/x86/mm/extable.c
> @@ -375,6 +375,7 @@ int fixup_exception(struct pt_regs *regs, int
> trapnr, unsigned long error_code,
> extern unsigned int early_recursion_flag;
>
> /* Restricted version used during very early boot */
> +__attribute__((optimize("O2")))
> void __init early_fixup_exception(struct pt_regs *regs, int trapnr)
> {
> /* Ignore early NMIs. */
> --
> 2.53.0
>
> --
> KISS == Keep it simple,stupid~:-)
> http://lizeliang.org
--
KISS == Keep it simple,stupid~:-)
http://lizeliang.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
2026-08-13 19:57 ` 李则良
@ 2026-08-14 10:15 ` Jürgen Groß
0 siblings, 0 replies; 12+ messages in thread
From: Jürgen Groß @ 2026-08-14 10:15 UTC (permalink / raw)
To: 李则良, Peter Zijlstra
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Nathan Chancellor, Josh Poimboeuf,
linux-kernel
[-- Attachment #1.1.1: Type: text/plain, Size: 4614 bytes --]
On 13.08.26 21:57, 李则良 wrote:
> I am currently testing the more general approach shown below. Your
> review is also appreciated.
>
> on vmlinux-O1:
>
> 0xffffffff82f447de <+126>: ff 15 a4 a9 cf ff call QWORD PTR
> [rip+0xffffffffffcfa9a4] # 0xffffffff82c3f188 <pv_ops+8>
> 0xffffffff82f447e4 <+132>: eb f8 jmp
> 0xffffffff82f447de <early_fixup_exception+126>
> 0xffffffff82f447e6 <+134>: 5b pop rbx
> 0xffffffff82f447e7 <+135>: 41 5c pop r12
> 0xffffffff82f447e9 <+137>: 5d pop rbp
>
> on vmlinux-O2:
>
> 0xffffffff82f3bf4f <+127>: ff 15 33 32 d0 ff call QWORD PTR
> [rip+0xffffffffffd03233] # 0xffffffff82c3f188 <pv_ops+8>
> 0xffffffff82f3bf55 <+133>: eb f8 jmp
> 0xffffffff82f3bf4f <early_fixup_exception+127>
> 0xffffffff82f3bf57 <+135>: 5b pop rbx
> 0xffffffff82f3bf58 <+136>: 41 5c pop r12
> 0xffffffff82f3bf5a <+138>: 5d pop rbp
>
> This is an early draft – please review. Thanks in advance.
>
> From 5989dcf448e4d23ea4f3a0f91fec34f3dd25d26c Mon Sep 17 00:00:00 2001
> From: Zeliang Li <lizeliang.linux@gmail.com>
> Date: Fri, 14 Aug 2026 03:17:38 +0800
> Subject: [PATCH] x86/paravirt: Force RIP-relative paravirt calls under low
> optimization levels
>
> When compiling the kernel with non-standard lower optimization levels like
> -O1 (e.g., during specific debugging or framework testing setups) using
> newer toolchains like GCC 15.2.0, the compiler exhibits passive register
> hoisting. In complex code paths like early_fixup_exception(), it caches the
> base address of the global 'pv_ops' structure into a general-purpose register
> instead of issuing direct RIP-relative memory loads, producing:
>
> mov $0xffffffff82c3f180, %rbx
> call *0x8(%rbx)
>
> While this behavior is bypassed under aggressive -O2 optimizations, under -O1
> it leaves a register-relative indirect call. This violates the strict format
> assertion in the x86 alternative text-patching engine (alt_replace_call),
> which expects an 'ALT_FLAG_DIRECT_CALL' site to be a standard 6-byte
> RIP-relative indirect call (ff 15), leading to a boot-time kernel BUG.
>
> Fix this by changing the x86_64 paravirt inline assembly to use an "i"
> (immediate) constraint for the function pointer address, and explicitly
> reference it via (%rip) in the assembly template. This removes the
> toolchain's ability to select any other addressing mode, guaranteeing the
> emission of compliant 'call *pv_ops+offset(%rip)' sequences on x86_64
> regardless of the active compiler -O flag.
>
> For i386, the original "m" constraint is retained since RIP-relative
> addressing does not exist on 32-bit x86.
>
> Signed-off-by: Zeliang Li <lizeliang.linux@gmail.com>
> ---
> arch/x86/include/asm/paravirt_types.h | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index b4c4a23e77a1..e8047bdbed3a 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -184,8 +184,6 @@ struct paravirt_patch_template {
>
> extern struct paravirt_patch_template pv_ops;
>
> -#define paravirt_ptr(array, op) [paravirt_opptr] "m" (array.op)
> -
> /*
> * This generates an indirect call based on the operation type number.
> *
> @@ -197,9 +195,20 @@ extern struct paravirt_patch_template pv_ops;
> * OTOH since this is effectively a __nocfi indirect call, the paravirt stubs
> * don't need to bother with CFI prefixes.
> */
> +#ifdef CONFIG_X86_64
> +
> +#define paravirt_ptr(array, op) [paravirt_opptr] "i" (&(array.op))
> #define PARAVIRT_CALL \
> ANNOTATE_RETPOLINE_SAFE "\n\t" \
> - "call *%[paravirt_opptr]"
> + "call *%c[paravirt_opptr](%%rip);"
> +#else /* CONFIG_X86_32 */
> +
> +#define paravirt_ptr(array, op) [paravirt_opptr] "m" (array.op)
> +#define PARAVIRT_CALL \
> + ANNOTATE_RETPOLINE_SAFE "\n\t" \
> + "call *%[paravirt_opptr];"
> +
> +#endif /* CONFIG_X86_64 */
>
> /*
> * These macros are intended to wrap calls through one of the paravirt
Thanks for this solution. I like it much more, especially as it will avoid
any nasty compiler optimizations as the one you have observed.
When sending this as a proper patch you can add my:
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2026-08-14 10:15 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CANd6bgL=v+uReoQznRGKunZQApwV5ESHAQn2_MOt-J-=cPkm9g@mail.gmail.com>
2026-08-11 11:50 ` [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions Jürgen Groß
2026-08-12 9:22 ` 李则良
2026-08-12 11:00 ` Peter Zijlstra
2026-08-12 11:24 ` H. Peter Anvin
2026-08-12 15:30 ` Borislav Petkov
2026-08-12 17:14 ` 李则良
2026-08-12 19:01 ` H. Peter Anvin
2026-08-12 19:02 ` H. Peter Anvin
2026-08-13 9:51 ` Peter Zijlstra
2026-08-13 19:35 ` 李则良
2026-08-13 19:57 ` 李则良
2026-08-14 10:15 ` Jürgen Groß
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®