linux-kernel - Re: [PATCH] kvm: x86: disable KVM_FAST_MMIO

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: <20170816224815-mutt-send-email-mst@kernel.org>
Date:   Wed, 16 Aug 2017 22:59:11 +0300
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] kvm: x86: disable KVM_FAST_MMIO_BUS

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