Re: [PATCH 5.4 12/47] KVM: x86: avoid incorrect writes to host MSR_IA32_SPEC_CTRL

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Feb 26, 2021 at 12:27:49PM +0100, Paolo Bonzini wrote:
> On 26/02/21 12:03, Thomas Lamprecht wrote:
> > On 04.01.21 16:57, Greg Kroah-Hartman wrote:
> > > From: Paolo Bonzini <pbonzini@redhat.com>
> > > 
> > > [ Upstream commit 6441fa6178f5456d1d4b512c08798888f99db185 ]
> > > 
> > > If the guest is configured to have SPEC_CTRL but the host does not
> > > (which is a nonsensical configuration but these are not explicitly
> > > forbidden) then a host-initiated MSR write can write vmx->spec_ctrl
> > > (respectively svm->spec_ctrl) and trigger a #GP when KVM tries to
> > > restore the host value of the MSR.  Add a more comprehensive check
> > > for valid bits of SPEC_CTRL, covering host CPUID flags and,
> > > since we are at it and it is more correct that way, guest CPUID
> > > flags too.
> > > 
> > > For AMD, remove the unnecessary is_guest_mode check around setting
> > > the MSR interception bitmap, so that the code looks the same as
> > > for Intel.
> > > 
> > 
> > A git bisect between 5.4.86 and 5.4.98 showed that this breaks boot of QEMU
> > guests running Windows 10 20H2 on AMD Ryzen X3700 CPUs with a BSOD showing
> > "KERNEL SECURITY CHECK FAILURE".
> > 
> > Reverting this commit or setting the CPU type of the QEMU/KVM command from
> > host to qemu64 allows one to boot Windows 10 in the VM again.
> > 
> > I found a followup, commit 841c2be09fe4f495fe5224952a419bd8c7e5b455 [0],
> > which has a fixes line for this commit and mentions Zen2 AMD CPUs (which
> > the X3700 is).
> > Applying a backport of that commit on top of 5.4.98 stable tree fixed the
> > issue here see below for the backport I used, it applies also cleanly on the
> > more current 5.4.101 release.
> > 
> > So can you please add this patch to the stable trees that backported the
> > problematic upstream commit 6441fa6178f5456d1d4b512c08798888f99db185 ?
> > 
> > If I should submit this in any other way just ask, was not sure about
> > what works best with a patch which cannot be cherry-picked cleanly.
> 
> Ok, I'll submit it.
> 
> Thanks for the testing.

Does that mean I should not take the patch here in this email and that
you will submit it after some timeperiod, or that I should take this
patch as-is?

thanks,

greg k-h