[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YDjwxF2RyKnsQqF/@kroah.com>
Date: Fri, 26 Feb 2021 13:59:48 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Thomas Lamprecht <t.lamprecht@...xmox.com>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Jim Mattson <jmattson@...hat.com>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.4 12/47] KVM: x86: avoid incorrect writes to host
MSR_IA32_SPEC_CTRL
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@...hat.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
Powered by blists - more mailing lists