linux-kernel - Re: [PATCH v2 1/2] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2d00cefad4a5316357e76db7292e8d7ac2793eb1.camel@intel.com>
Date: Fri, 17 Oct 2025 10:53:05 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "pbonzini@...hat.com" <pbonzini@...hat.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>
CC: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "Williams, Dan J" <dan.j.williams@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Edgecombe,
 Rick P" <rick.p.edgecombe@...el.com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>
Subject: Re: [PATCH v2 1/2] KVM: VMX: Inject #UD if guest tries to execute
 SEAMCALL or TDCALL

> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -6728,6 +6728,14 @@ static bool nested_vmx_l1_wants_exit(struct kvm_vcpu *vcpu,
>  	case EXIT_REASON_NOTIFY:
>  		/* Notify VM exit is not exposed to L1 */
>  		return false;
> +	case EXIT_REASON_SEAMCALL:
> +	case EXIT_REASON_TDCALL:
> +		/*
> +		 * SEAMCALL and TDCALL unconditionally VM-Exit, but aren't
> +		 * virtualized by KVM for L1 hypervisors, i.e. L1 should
> +		 * never want or expect such an exit.
> +		 */
> +		return false;

Sorry for commenting late.

I think from emulating hardware behaviour's perspective, if L1 doesn't
support TDX (obviously true), SEAMCALL/TDCALL in L2 should cause VMEXIT to
L1.  In other words, L1 is expecting a VMEXIT in such case.  Whether L1
can handle such VMEXIT is another story -- it may inject a #UD to L2 or
may not (similar to the current upstream KVM), but it is L1's
responsibility.

So I think while this patch certainly honors the correct behaviour for L2,
it doesn't honor for L1.  But I think ultimately L1 should be the one who
is responsible for emulating hardware behaviour for L2.

E.g., assuming we have a KVM selftest in L1 to test SEAMCALL/TDCALL in
normal VMX L2.  L1 should be able to catch it's own bug when such VMEXIT
isn't handled correctly.  But with this patch, L1 will never be able to
catch this IIUC.