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: <ZhRxWxRLbnrqwQYw@google.com>
Date: Mon, 8 Apr 2024 15:36:11 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: "davidskidmore@...gle.com" <davidskidmore@...gle.com>, Xiaoyao Li <xiaoyao.li@...el.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"srutherford@...gle.com" <srutherford@...gle.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"pankaj.gupta@....com" <pankaj.gupta@....com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Wei W Wang <wei.w.wang@...el.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

On Mon, Apr 08, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-04-08 at 18:51 +0000, Sean Christopherson wrote:
> > > I'm not following the code examples involving struct kvm_vcpu. Since TDX
> > > configures these at a VM level, there isn't a vcpu.
> > 
> > Ah, I take it GPAW is a VM-scope knob?
> 
> Yea.
> 
> > I forget where we ended up with the ordering of TDX commands vs. creating
> > vCPUs.  Does KVM allow creating vCPU structures in advance of the TDX INIT
> > call?  If so, the least awful solution might be to use vCPU0's CPUID.
> 
> Currently the values for the directly settable CPUID leafs come via a TDX
> specific init VM userspace API.

Is guest.MAXPHYADDR one of those?  If so, use that.

> So should we look at making the TDX side follow a
> KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID pattern for feature enablement? Or am I
> misreading general guidance out of this specific suggestion around GPAW? 

No?  Where I was going with that, is _if_ vCPUs can be created (in KVM) before
the GPAW is set (in the TDX module), then using vCPU0's guest.MAXPHYADDR to
compute the desired GPAW may be the least awful solution, all things considered.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ