* [PATCH] x86/pvh: Call C code via the kernel virtual mapping
@ 2025-04-11 16:08 Jason Andryuk
2025-04-18 20:32 ` Jason Andryuk
0 siblings, 1 reply; 3+ messages in thread
From: Jason Andryuk @ 2025-04-11 16:08 UTC (permalink / raw)
To: stable; +Cc: Ard Biesheuvel, Jason Andryuk, Juergen Gross
From: Ard Biesheuvel <ardb@kernel.org>
[ Upstream commit e8fbc0d9cab6c1ee6403f42c0991b0c1d5dbc092 ]
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So call xen_prepare_pvh() via its kernel virtual mapping on x86_64, so
that those RIP-relative references produce the correct values. This
matches the pre-existing behavior for i386, which also invokes
xen_prepare_pvh() via the kernel virtual mapping before invoking
startup_32 with paging disabled again.
Fixes: 7243b93345f7 ("xen/pvh: Bootstrap PVH guest")
Tested-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Message-ID: <20241009160438.3884381-8-ardb+git@google.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
[ Stable context update ]
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
Stable backport for 6.6 .. 5.10.
Direct cherry-pick needed context fixups, which are made here. This
upstream commit was previously included in stable, but with the pre-req
of b464b461d27d ("x86/pvh: Set phys_base when calling
xen_prepare_pvh()"). Both were subsequently reverted as b464b461d27d
caused regressions. This backport, e8fbc0d9cab6, in isolation is
correct.
This fixes a regression introduced by the backport of upstream commit
b4845bb6383821a9516ce30af3a27dc873e37fd4 ("x86/xen: add central
hypercall functions")
b4845bb63838 adds a comparison between rip-relative xen_hypercall_amd()
and kernel virtual address of xen_hypercall_amd() to determine whether
to use the AMD or Intel variant. When running from the identity mapped
address, the comparison always fail. The leads to calling
xen_hypercall_intel(), even on AMD processors, which faults and halts
boot. This affects PVH dom0 - domU doesn't seem to be affected.
This patch performs the rip-relative mapping from the kernel virtual
mapping, so the values can be properly compared.
---
arch/x86/platform/pvh/head.S | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index c4365a05ab83..fc46b4dfbd74 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -100,7 +100,12 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
xor %edx, %edx
wrmsr
- call xen_prepare_pvh
+ /* Call xen_prepare_pvh() via the kernel virtual mapping */
+ leaq xen_prepare_pvh(%rip), %rax
+ subq phys_base(%rip), %rax
+ addq $__START_KERNEL_map, %rax
+ ANNOTATE_RETPOLINE_SAFE
+ call *%rax
/* startup_64 expects boot_params in %rsi. */
mov $_pa(pvh_bootparams), %rsi
--
2.49.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] x86/pvh: Call C code via the kernel virtual mapping
2025-04-11 16:08 [PATCH] x86/pvh: Call C code via the kernel virtual mapping Jason Andryuk
@ 2025-04-18 20:32 ` Jason Andryuk
2025-04-19 6:00 ` Greg Kroah-Hartman
0 siblings, 1 reply; 3+ messages in thread
From: Jason Andryuk @ 2025-04-18 20:32 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, sashal; +Cc: Ard Biesheuvel, Juergen Gross
Hi Greg and Sasha,
It's been a week, so I'm following up on the status of this.
Should I use a different tag than "PATCH" when sending a manual fixup?
Thanks,
Jason
On 2025-04-11 12:08, Jason Andryuk wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> [ Upstream commit e8fbc0d9cab6c1ee6403f42c0991b0c1d5dbc092 ]
>
> Calling C code via a different mapping than it was linked at is
> problematic, because the compiler assumes that RIP-relative and absolute
> symbol references are interchangeable. GCC in particular may use
> RIP-relative per-CPU variable references even when not using -fpic.
>
> So call xen_prepare_pvh() via its kernel virtual mapping on x86_64, so
> that those RIP-relative references produce the correct values. This
> matches the pre-existing behavior for i386, which also invokes
> xen_prepare_pvh() via the kernel virtual mapping before invoking
> startup_32 with paging disabled again.
>
> Fixes: 7243b93345f7 ("xen/pvh: Bootstrap PVH guest")
> Tested-by: Jason Andryuk <jason.andryuk@amd.com>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> Message-ID: <20241009160438.3884381-8-ardb+git@google.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> [ Stable context update ]
> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
> ---
> Stable backport for 6.6 .. 5.10.
>
> Direct cherry-pick needed context fixups, which are made here. This
> upstream commit was previously included in stable, but with the pre-req
> of b464b461d27d ("x86/pvh: Set phys_base when calling
> xen_prepare_pvh()"). Both were subsequently reverted as b464b461d27d
> caused regressions. This backport, e8fbc0d9cab6, in isolation is
> correct.
>
> This fixes a regression introduced by the backport of upstream commit
> b4845bb6383821a9516ce30af3a27dc873e37fd4 ("x86/xen: add central
> hypercall functions")
>
> b4845bb63838 adds a comparison between rip-relative xen_hypercall_amd()
> and kernel virtual address of xen_hypercall_amd() to determine whether
> to use the AMD or Intel variant. When running from the identity mapped
> address, the comparison always fail. The leads to calling
> xen_hypercall_intel(), even on AMD processors, which faults and halts
> boot. This affects PVH dom0 - domU doesn't seem to be affected.
>
> This patch performs the rip-relative mapping from the kernel virtual
> mapping, so the values can be properly compared.
> ---
> arch/x86/platform/pvh/head.S | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
> index c4365a05ab83..fc46b4dfbd74 100644
> --- a/arch/x86/platform/pvh/head.S
> +++ b/arch/x86/platform/pvh/head.S
> @@ -100,7 +100,12 @@ SYM_CODE_START_LOCAL(pvh_start_xen)
> xor %edx, %edx
> wrmsr
>
> - call xen_prepare_pvh
> + /* Call xen_prepare_pvh() via the kernel virtual mapping */
> + leaq xen_prepare_pvh(%rip), %rax
> + subq phys_base(%rip), %rax
> + addq $__START_KERNEL_map, %rax
> + ANNOTATE_RETPOLINE_SAFE
> + call *%rax
>
> /* startup_64 expects boot_params in %rsi. */
> mov $_pa(pvh_bootparams), %rsi
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] x86/pvh: Call C code via the kernel virtual mapping
2025-04-18 20:32 ` Jason Andryuk
@ 2025-04-19 6:00 ` Greg Kroah-Hartman
0 siblings, 0 replies; 3+ messages in thread
From: Greg Kroah-Hartman @ 2025-04-19 6:00 UTC (permalink / raw)
To: Jason Andryuk; +Cc: stable, sashal, Ard Biesheuvel, Juergen Gross
On Fri, Apr 18, 2025 at 04:32:35PM -0400, Jason Andryuk wrote:
> Hi Greg and Sasha,
>
> It's been a week, so I'm following up on the status of this.
Please relax, right now I have 477 "backports" to dig through for stable
tree inclusion, including your 4 emails. They will be processed
eventually, when we have the time to do so. Newest kernel trees are
always handled first, and then we move down to older ones.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-04-19 6:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-11 16:08 [PATCH] x86/pvh: Call C code via the kernel virtual mapping Jason Andryuk
2025-04-18 20:32 ` Jason Andryuk
2025-04-19 6:00 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox