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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Apr 2024 18:51:40 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Rick Edgecombe <rick.p.edgecombe@...el.com>
Cc: Xiaoyao Li <xiaoyao.li@...el.com>, 
	"davidskidmore@...gle.com" <davidskidmore@...gle.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"pankaj.gupta@....com" <pankaj.gupta@....com>, "srutherford@...gle.com" <srutherford@...gle.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Wei Wang <wei.w.wang@...el.com>, 
	Isaku Yamahata <isaku.yamahata@...el.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

On Mon, Apr 08, 2024, Edgecombe, Rick P wrote:
> On Mon, 2024-04-08 at 09:20 -0700, Sean Christopherson wrote:
> > > Another option is that, KVM doesn't allow userspace to configure
> > > CPUID(0x8000_0008).EAX[7:0]. Instead, it provides a gpaw field in struct
> > > kvm_tdx_init_vm for userspace to configure directly.
> > > 
> > > What do you prefer?
> > 
> > Hmm, neither.  I think the best approach is to build on Gerd's series to have KVM
> > select 4-level vs. 5-level based on the enumerated guest.MAXPHYADDR, not on
> > host.MAXPHYADDR.
> 
> So then GPAW would be coded to basically best fit the supported guest.MAXPHYADDR within KVM. QEMU
> could look at the supported guest.MAXPHYADDR and use matching logic to determine GPAW.

Off topic, any chance I can bribe/convince you to wrap your email replies closer
to 80 chars, not 100?  Yeah, checkpath no longer complains when code exceeds 80
chars, but my brain is so well trained for 80 that it actually slows me down a
bit when reading mails that are wrapped at 100 chars.

> Or are you suggesting that KVM should look at the value of CPUID(0X8000_0008).eax[23:16] passed from
> userspace?

This.  Note, my pseudo-patch incorrectly looked at bits 15:8, that was just me
trying to go off memory.

> 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?  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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ