linux-kernel - Re: [PATCH v19 130/130] RFC: KVM: x86, TDX: Add check for KVM_SET

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]

Date: Fri, 22 Mar 2024 07:10:42 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Edgecombe,
 Rick P" <rick.p.edgecombe@...el.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "Yuan, Hang" <hang.yuan@...el.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "Chen, Bo2" <chen.bo@...el.com>,
	"sagis@...gle.com" <sagis@...gle.com>, "isaku.yamahata@...il.com"
	<isaku.yamahata@...il.com>, "Aktas, Erdem" <erdemaktas@...gle.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>
Subject: Re: [PATCH v19 130/130] RFC: KVM: x86, TDX: Add check for
 KVM_SET_CPUID2

On Thu, 2024-03-21 at 23:12 +0000, Edgecombe, Rick P wrote:
> On Mon, 2024-02-26 at 00:27 -0800, isaku.yamahata@...el.com wrote:
> > Implement a hook of KVM_SET_CPUID2 for additional consistency check.
> > 
> > Intel TDX or AMD SEV has a restriction on the value of cpuid.  For
> > example,
> > some values must be the same between all vcpus.  Check if the new
> > values
> > are consistent with the old values.  The check is light because the
> > cpuid
> > consistency is very model specific and complicated.  The user space
> > VMM
> > should set cpuid and MSRs consistently.
> 
> I see that this was suggested by Sean, but can you explain the problem
> that this is working around? From the linked thread, it seems like the
> problem is what to do when userspace also calls SET_CPUID after already
> configuring CPUID to the TDX module in the special way. The choices
> discussed included:
> 1. Reject the call
> 2. Check the consistency between the first CPUID configuration and the
> second one.
> 
> 1 is a lot simpler, but the reasoning for 2 is because "some KVM code
> paths rely on guest CPUID configuration" it seems. Is this a
> hypothetical or real issue? Which code paths are problematic for
> TDX/SNP?

There might be use case that TDX guest wants to use some CPUID which
isn't handled by the TDX module but purely by KVM.  These (PV) CPUIDs need to be
provided via KVM_SET_CPUID2.


Btw, Isaku, I don't understand why you tag the last two patches as RFC and put
them at last.  I think I've expressed this before.  Per the discussion with
Sean, my understanding is this isn't something optional but the right thing we
should do?

https://lore.kernel.org/lkml/ZDiGpCkXOcCm074O@google.com/