linux-kernel - Re: [PATCH 7/7] KVM: TDX: Add TSX_CTRL msr into uret

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: <44c67438cf3b2b1ce63dbc8f21fef18614805ed8.camel@intel.com>
Date: Wed, 4 Dec 2024 23:51:22 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "Hunter, Adrian"
	<adrian.hunter@...el.com>, "Gao, Chao" <chao.gao@...el.com>
CC: "Yang, Weijiang" <weijiang.yang@...el.com>, "x86@...nel.org"
	<x86@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, "Huang, Kai" <kai.huang@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Zhao, Yan Y"
	<yan.y.zhao@...el.com>, "tony.lindgren@...ux.intel.com"
	<tony.lindgren@...ux.intel.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"dmatlack@...gle.com" <dmatlack@...gle.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"nik.borisov@...e.com" <nik.borisov@...e.com>
Subject: Re: [PATCH 7/7] KVM: TDX: Add TSX_CTRL msr into uret_msrs list

On Wed, 2024-12-04 at 23:33 +0800, Xiaoyao Li wrote:
> > 
> 
> There were discussion[1] on whether KVM to gatekeep the 
> configurable/supported CPUIDs for TDX. I stand by Sean that KVM needs to 
> do so.
> 
> Regarding KVM opt in the new feature, KVM gatekeeps the CPUID bit that 
> can be set by userspace is exactly the behavior of opt-in. i.e., for a 
> given KVM, it only allows a CPUID set {S} to be configured by userspace, 
> if new TDX module supports new feature X, it needs KVM to opt-in X by 
> adding X to {S} so that X is allowed to be configured by userspace.
> 
> Besides, I find current interface between KVM and userspace lacks the 
> ability to tell userspace what bits are not supported by KVM. 
> KVM_TDX_CAPABILITIES.cpuid doesn't work because it represents the 
> configurable CPUIDs, not supported CPUIDs (I think we might rename it to 
> configurable_cpuid to better reflect its meaning). So userspace has to 
> hardcode that TSX and WAITPKG is not support itself.
> 
> [1] https://lore.kernel.org/all/ZuM12EFbOXmpHHVQ@google.com/

I mean, this is kind of a good example for why we might want to go back to
filtering CPUID bits. It kind of depends on how KVM wants to treat the TDX
module. Hostile like userspace, or more trusting. KVM maintaining code to let
the TDX module evolve unsafely would be unfortunate though.

If we keep the current approach, it probably would be educational to highlight
this example to the TDX module team. "Don't do this or you will have a bug on
your side".