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
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
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
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Jason Andryuk