mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 --]

      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®