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]

Date:   Wed, 16 Aug 2017 21:03:17 +0200
From:   Radim Krčmář <rkrcmar@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     "Michael S. Tsirkin" <mst@...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

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 ... KVM uses standard
features and SDM clearly says that the instruction length field is
undefined.

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.