Re: [PATCH v3 2/3] x86/vmware: Route low-bandwidth hypercalls through a static call

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] x86/vmware: broken TDX hypercall guard when vmware_init_hypercall() is skipped
--

commit fc9641d4edae98b08577710c597ef17cc2f5765e
Author: Alexey Makhalov <alexey.makhalov@broadcom.com>

x86/vmware: Route low-bandwidth hypercalls through a static call

This commit consolidates the low-bandwidth VMware hypercall inline assembly
into four backend functions dispatched via a static call, passing arguments
and results through structures rather than nullable pointers.

Link: https://lore.kernel.org/r/20260309235250.2611115-2-alexey.makhalov@broadcom.com
Link: https://lore.kernel.org/all/CAHk-=wivx7pi+h+hGmvNFAJm6StQLiQ-b8DdsE5J=LMOWae8Ng@mail.gmail.com/

[Severity: Medium]
In arch/x86/kernel/cpu/vmware.c, vmware_init_hypercall() (around line 510)
updates the vmware_hypercall static call to vmware_tdx_hypercall() when
X86_FEATURE_TDX_GUEST is enabled, while the link-time default for
vmware_hypercall is vmware_backdoor_hypercall().

Previously, vmware_hypercall1() through vmware_hypercall7() in
arch/x86/include/asm/vmware.h checked cpu_feature_enabled(X86_FEATURE_TDX_GUEST)
directly and called vmware_tdx_hypercall(), which rejected non-VMware TDX
guests via !hypervisor_is_type(X86_HYPER_VMWARE) (around line 633 of
arch/x86/kernel/cpu/vmware.c) and returned ULONG_MAX.

With this change, vmware_init_hypercall() is only invoked from
vmware_platform_setup(), which only runs when VMware is the detected
hypervisor. On a TDX guest running under KVM (where x86_hyper_type is
X86_HYPER_KVM), vmware_platform_setup() does not run, leaving the
vmware_hypercall static call pointing at vmware_backdoor_hypercall().

When vmmouse_detect() in drivers/input/mouse/vmmouse.c (line 323) runs on a
KVM TDX guest (since vmmouse_supported_hypervisors[] includes X86_HYPER_KVM)
and calls vmware_hypercall3(VMWARE_CMD_GETVERSION, ...), won't it execute
the port I/O instruction inl (0x5658) in vmware_backdoor_hypercall() instead
of being blocked by vmware_tdx_hypercall()? In a TDX guest, executing inl
triggers a #VE exception and issues a TDG.VP.VMCALL<Instruction.IO> to the
VMM, which will raise a kernel #GP(0) fault via ve_raise_fault() if the VMM
rejects port 0x5658 I/O.

Additionally, since vmware_tdx_hypercall() is now only installed after
x86_hyper_type has already been set to X86_HYPER_VMWARE, doesn't the
!hypervisor_is_type(X86_HYPER_VMWARE) check inside vmware_tdx_hypercall()
become unreachable?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793685318.git.zack.rusin@broadcom.com?part=2