On Tue, Nov 3, 2026 at 2:34 AM <[email protected]> wrote: > > 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 <[email protected]> > > 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/[email protected] > Link: > https://lore.kernel.org/all/CAHk-=wivx7pi+h+hGmvNFAJm6StQLiQ-b8DdsE5J=lmowae...@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?
Those are valid. I forgot that various pieces of the vmware driver code are running on other hypervisors... I'll respin v4 of this series tomorrow. z
smime.p7s
Description: S/MIME Cryptographic Signature
