linux-kernel - Re: [PATCH v3 00/27] Enable FRED with KVM VMX

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: <Z73_TwUgIsceWyzQ@google.com>
Date: Tue, 25 Feb 2025 09:35:11 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Xin Li <xin@...or.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-doc@...r.kernel.org, Chao Gao <chao.gao@...el.com>, pbonzini@...hat.com, 
	corbet@....net, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, luto@...nel.org, 
	peterz@...radead.org, andrew.cooper3@...rix.com
Subject: Re: [PATCH v3 00/27] Enable FRED with KVM VMX

On Tue, Feb 25, 2025, Xin Li wrote:
> On 2/25/2025 7:24 AM, Sean Christopherson wrote:
> > On Tue, Feb 18, 2025, Xin Li wrote:
> > > On 9/30/2024 10:00 PM, Xin Li (Intel) wrote:
> > > While I'm waiting for the CET patches for native Linux and KVM to be
> > > upstreamed, do you think if it's worth it for you to take the cleanup
> > > and some of the preparation patches first?
> > 
> > Yes, definitely.  I'll go through the series and see what I can grab now.
> 
> I planned to do a rebase and fix the conflicts due to the reordering.
> But I'm more than happy you do a first round.

For now, I'm only going to grab these:

  KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
  KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
  KVM: x86: Use a dedicated flow for queueing re-injected exceptions

and the WRMSRNS patch.  I'll post (and apply, if it looks good) the entry/exit
pairs patch separately.

Easiest thing would be to rebase when all of those hit kvm-x86/next.

> BTW, if you plan to take
> 	KVM: VMX: Virtualize nested exception tracking

I'm not planning on grabbing this in advance of the FRED series, especially if
it's adding new uAPI.  The code doesn't need to exist without FRED, and doesn't
really make much sense to readers without the context of FRED.

> > > Top of my mind are:
> > >      KVM: x86: Use a dedicated flow for queueing re-injected exceptions
> > >      KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
> > >      KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM

As above, I'll grab these now.

> > >      KVM: nVMX: Add a prerequisite to existence of VMCS fields
> > >      KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros

Unless there's a really, really good reason to add precise checking, I strongly
prefer to skip these entirely.

> > > 
> > > Then specially, the nested exception tracking patch seems a good one as
> > > Chao Gao suggested to decouple the nested tracking from FRED:
> > >      KVM: VMX: Virtualize nested exception tracking
> > > 
> > > Lastly the patches to add support for the secondary VM exit controls might
> > > go in early as well:
> > >      KVM: VMX: Add support for the secondary VM exit controls
> > >      KVM: nVMX: Add support for the secondary VM exit controls

Unless there's another feature on the horizon that depends on secondary exit controls,
(and y'all will be posted patches soon), I'd prefer just grab these in the FRED
series.  With the pairs check prep work out of the way, adding support for the
new controls should be very straightforward, and shouldn't conflict with anything.