All of lore.kernel.org
 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 ` [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 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 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.