* 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; 6+ 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] 6+ 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; 6+ 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 related [flat|nested] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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; 6+ 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] 6+ 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 ` 李则良
1 sibling, 0 replies; 6+ 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] 6+ messages in thread
end of thread, other threads:[~2026-08-12 17:14 UTC | newest]
Thread overview: 6+ 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 ` 李则良
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.