DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8EB0964D99
Date: Wed, 16 Aug 2017 22:59:11 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] kvm: x86: disable KVM_FAST_MMIO_BUS
Message-ID: <20170816224815-mutt-send-email-mst@kernel.org>
References: <20170816112249.28939-1-pbonzini@redhat.com>
 <20170816155132-mutt-send-email-mst@kernel.org>
 <9de5ebf5-457d-2a34-0314-c6c612ddb2e9@redhat.com>
 <20170816161301-mutt-send-email-mst@kernel.org>
 <fb384aa5-6b8a-4d70-98bb-2ce2adbcaab4@redhat.com>
 <20170816194342-mutt-send-email-mst@kernel.org>
 <81dabc78-edfd-32fc-024c-c57330386a51@redhat.com>
 <20170816190316.GA2566@flask>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170816190316.GA2566@flask>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2656
Lines: 64

On Wed, Aug 16, 2017 at 09:03:17PM +0200, Radim Krčmář wrote:
> 2017-08-16 19:19+0200, Paolo Bonzini:
> > On 16/08/2017 18:50, Michael S. Tsirkin wrote:
> >> On Wed, Aug 16, 2017 at 03:30:31PM +0200, Paolo Bonzini wrote:
> >>> While you can filter out instruction fetches, that's not enough.  A data
> >>> read could happen because someone pointed the IDT to MMIO area, and who
> >>> knows what the VM-exit instruction length points to in that case.
> >> 
> >> Thinking more about it, I don't really see how anything
> >> legal guest might be doing with virtio would trigger anything
> >> but a fault after decoding the instruction. How does
> >> skipping instruction even make sense in the example you give?
> > 
> > There's no such thing as a legal guest.  Anything that the hypervisor
> > does, that differs from real hardware, is a possible escalation path.
> > 
> > This in fact makes me doubt the EMULTYPE_SKIP patch too.
> 
> The main hack is that we expect EPT misconfig within a given range to be
> a MMIO NULL write.  I think it is fine -- EMULTYPE_SKIP is a common path
> that should have well tested error paths and, IIUC, virtio doesn't allow
> any other access, so it is a problem of the guest if a buggy/malicious
> application can access virtio memory.
> 
> >>>>> Plus of course it wouldn't be guaranteed to work on nested.
> >>>>
> >>>> Not sure I got this one.
> >>>
> >>> Not all nested hypervisors are setting the VM-exit instruction length
> >>> field on EPT violations, since it's documented not to be set.
> >> 
> >> So that's probably the real issue - nested virt which has to do it
> >> in software at extra cost. We already limit this to intel processors,
> 
> Hm, there is no reason to exclude SVM.
> 
> >> how about we blacklist nested virt for this optimization?
> 
> Not every hypervisor can be easily detected ...

Hypervisors that don't set a hypervisor bit in CPUID are violating the
spec themselves, aren't they?  Anyway, we can add a management option
for use in a nested scenario.

> KVM uses standard
> features and SDM clearly says that the instruction length field is
> undefined.

True. Let's see whether intel can commit to a stronger definition.
I don't think there's any rush to make this change.


> We only lose performance if we decode the instruction, but piling
> workarounds creates unexpected corner cases.
> 
> I still don't see acceptable alternatives to Paolo's solution.

It's just that this has been there for 3 years and people have built a
product around this. It's not a feature you can discard out of hand out
of theoretical concerns or to improve niche use-cases such as nested
virt.

-- 
MST