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

On Mon, 2024-12-02 at 16:34 -0800, Sean Christopherson wrote:
> > Small point - the last conversation[0] we had on this was to let *userspace*
> > ensure consistency between KVM's CPUID (i.e. KVM_SET_CPUID2) and the TDX
> > Module's view.
> 
> I'm all for that, right up until KVM needs to protect itself again userspace
> and
> flawed TDX architecture.  A relevant comment I made in that thread:
> 
>  : If the upgrade breaks a setup because it confuses _KVM_, then I'll care
> 
> As it applies here, letting vCPU CPUID and actual guest functionality diverge
> for
> features that KVM cares about _will_ cause problems.

Right, just wanted to make sure we don't need to re-open the major design.

> 
> This will be less ugly to handle once kvm_vcpu_arch.cpu_caps is a thing.  KVM
> can simply force set/clear bits to match the actual guest functionality that's
> hardcoded by the TDX Module or defined by TDPARAMS.
> 
> > So the configuration goes:
> > 1. Userspace configures per-VM CPU features
> > 2. Userspace gets TDX Module's final per-vCPU version of CPUID configuration
> > via
> > KVM API
> > 3. Userspace calls KVM_SET_CPUID2 with the merge of TDX Module's version,
> > and
> > userspace's desired values for KVM "owned" CPUID leads (pv features, etc)
> > 
> > But KVM's knowledge of CPUID bits still remains per-vcpu for TDX in any
> > case.
> > 
> > > 
> > >  - Don't hardcode fixed/required CPUID values in KVM, use available
> > > metadata
> > >    from TDX Module to reject "bad" guest CPUID (or let the TDX module
> > > reject?).
> > >    I.e. don't let a guest silently run with a CPUID that diverges from
> > > what
> > >    userspace provided.
> > 
> > The latest QEMU patches have this fixed bit data hardcoded in QEMU. Then the
> > long term solution is to make the TDX module return this data. Xiaoyao will
> > post
> > a proposal on how the TDX module should expose this soon.
> 
> Punting the "merge" to userspace is fine, but KVM still needs to ensure it
> doesn't
> have holes where userspace can attack the kernel by lying about what features
> the
> guest has access to.  And that means forcing bits in kvm_vcpu_arch.cpu_caps;
> anything else is just asking for problems.

Ok, then for now let's just address them on a case-by-case basis for logic that
protects KVM. I'll add to look at using kvm_vcpu_arch.cpu_caps to our future-
things todo list.

I think Adrian is going post a proposal for how to handle this case better.