Message-ID: <CABgObfZ+bMOac-yf2v6jD+s0-_RXACY3ApDknC2FnTmmgDXEug@mail.gmail.com>
Date: Thu, 29 Feb 2024 11:04:45 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Greg KH <gregkh@...nel.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org, 
	KVM list <kvm@...r.kernel.org>, Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: CVE-2021-46978: KVM: nVMX: Always make an attempt to map eVMCS
 after migration

On Thu, Feb 29, 2024 at 6:21 AM Greg KH <gregkh@...nel.org> wrote:
>
> On Wed, Feb 28, 2024 at 11:09:50PM +0100, Paolo Bonzini wrote:
> > On 2/28/24 09:14, Greg Kroah-Hartman wrote:
> > > From: gregkh@...nel.org
> > >
> > > Description
> > > ===========
> > >
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > KVM: nVMX: Always make an attempt to map eVMCS after migration
> >
> > How does this break the confidentiality, integrity or availability of the
> > host kernel?  It's a fix for a failure to restart the guest after migration.
> > Vitaly can confirm.
>
> It's a fix for the availability of the guest kernel, which now can not
> boot properly, right?  That's why this was selected.  If this is not
> correct, I will be glad to revoke this.

To expand on what Vitaly touched, guest availability based on host
action is generally not considered part of the threat model (not even
by the newfangled confidential computing stuff). If you want to stop a
guest, run "virsh pause" or kill -9. Add load to the host until the
guest reports a lockup. dd if=/dev/random to their disk. Or if you
need to bypass SELinux, just turn off the host---in CVSS parlance,
that would be a valid attack on an "adjacent" machine, but nobody
treats it as such and the reason should be obvious.

Yes, there can be mitigations but let's say that "orchestrate a fake
migration so that the guest fails to restart on the destination" is
fairly down on the checklsit.

> > Apparently the authority to "dispute or modify an assigned CVE lies solely
> > with the maintainers", but we don't have the authority to tell you in
> > advance that a CVE is crap, so please consider this vulnerability to be
> > disputed.
>
> Great, but again, not allowing the guest kernel to boot again feels like
> an "availability" issue to me.  If not, we can revoke this.
>
> > Unlike what we discussed last week:
> >
> > - the KVM list is not CC'd so whoever sees this reply will have to find the
> > original message on their own
>
> Adding a cc: to the subsystem mailing list for the CVEs involved can be
> done, but would it really help much?

Yes, it would give a heads up like you do for stable patches roundup.

> > - there is no list gathering all the discussions/complaints about these
> > CVEs, since I cannot reply to linux-cve-announce@...r.kernel.org.
>
> That's what lkml is for, and is why the "Reply-to:" is set on the
> linux-cve-announce emails.  Creating yet-another-list isn't really going
> to help much.

So why do we have subsystem lists at all? It helps people that have
interest in proposing and gathering CVE disputes, providing an easy
way to do so; just like subsystem mailing lists people that are
interested in USB or virtualization patches. It helps searching for
all messages related to a CVE by not splitting them between
linux-cve-announce and lkml, too.

Also, LKML does not get the initial announcement, which makes it a bit
more painful to find the full discussion on lore (you have to go
through a "no message with that id, maybe you mean this one from other
mailing lists" page, instead of having the whole thread in the same
place). A linux-cve mailing list with public posting, used for Cc and
Reply-to of the initial message, would solve this issue as well.

Paolo

Powered by blists - more mailing lists