From: "Jürgen Groß" <jgross@suse.com>
To: 李则良 <lizeliang.linux@gmail.com>, "Peter Zijlstra" <peterz@infradead.org>
Cc: 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, "H. Peter Anvin" <hpa@zytor.com>,
Kees Cook <kees@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/alternatives: gracefully skip unrecognized indirect call instructions
Date: Fri, 14 Aug 2026 12:15:35 +0200 [thread overview]
Message-ID: <46e601cf-3915-4c93-9df1-74082417a668@suse.com> (raw)
In-Reply-To: <CANd6bgJW51rhUxqU=W8tFUT0BE=Y+Ac0TRu5uLxeXGBVsevtnw@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2026-08-14 10:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANd6bgL=v+uReoQznRGKunZQApwV5ESHAQn2_MOt-J-=cPkm9g@mail.gmail.com>
2026-08-11 11:50 ` 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 message]
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=46e601cf-3915-4c93-9df1-74082417a668@suse.com \
--to=jgross@suse.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizeliang.linux@gmail.com \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/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®