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? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
