linux-kernel - Re: [PATCH] x86/cpu: Add a VMX flag to enumerate 5-level EPT support to userspace

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: <ZaCRFPIMfAPNy2rU@linux.bj.intel.com>
Date: Fri, 12 Jan 2024 09:08:36 +0800
From: Tao Su <tao1.su@...ux.intel.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Chao Gao <chao.gao@...el.com>, Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Yi Lai <yi1.lai@...el.com>, Xudong Hao <xudong.hao@...el.com>
Subject: Re: [PATCH] x86/cpu: Add a VMX flag to enumerate 5-level EPT support
 to userspace

On Thu, Jan 11, 2024 at 08:25:01AM -0800, Sean Christopherson wrote:
> On Thu, Jan 11, 2024, Tao Su wrote:
> > On Wed, Jan 10, 2024 at 08:26:25AM -0800, Sean Christopherson wrote:
> > > On Wed, Jan 10, 2024, Chao Gao wrote:
> > > > On Tue, Jan 09, 2024 at 04:23:40PM -0800, Sean Christopherson wrote:
> > > > >Add a VMX flag in /proc/cpuinfo, ept_5level, so that userspace can query
> > > > >whether or not the CPU supports 5-level EPT paging.  EPT capabilities are
> > > > >enumerated via MSR, i.e. aren't accessible to userspace without help from
> > > > >the kernel, and knowing whether or not 5-level EPT is supported is sadly
> > > > >necessary for userspace to correctly configure KVM VMs.
> > > > 
> > > > This assumes procfs is enabled in Kconfig and userspace has permission to
> > > > access /proc/cpuinfo. But it isn't always true. So, I think it is better to
> > > > advertise max addressable GPA via KVM ioctls.
> > > 
> > > Hrm, so the help for PROC_FS says:
> > > 
> > >   Several programs depend on this, so everyone should say Y here.
> > > 
> > > Given that this is working around something that is borderline an erratum, I'm
> > > inclined to say that userspace shouldn't simply assume the worst if /proc isn't
> > > available.  Practically speaking, I don't think a "real" VM is likely to be
> > > affected; AFAIK, there's no reason for QEMU or any other VMM to _need_ to expose
> > > a memslot at GPA[51:48] unless the VM really has however much memory that is
> > > (hundreds of terabytes?).  And a if someone is trying to run such a massive VM on
> > > such a goofy CPU...
> > 
> > It is unusual to assign a huge RAM to guest, but passthrough a device also may trigger
> > this issue which we have met, i.e. alloc memslot for the 64bit BAR which can set
> > bits[51:48]. BIOS can control the BAR address, e.g. seabios moved 64bit pci window
> > to end of address space by using advertised physical bits[1].
> 
> Drat.  Do you know if these CPUs are going to be productized?  We'll still need
> something in KVM either way, but whether or not the problems are more or less
> limited to funky software setups might influence how we address this.

Yes, please see the CPU model I submitted[1].

[1] https://lore.kernel.org/all/20231206131923.1192066-1-tao1.su@linux.intel.com/

Thanks,
Tao

>