linux-kernel - Re: [PATCH v6 05/13] KVM: nVMX: implement enlightened VMPTRLD and VMCLEAR

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] [day] [month] [year] [list]

Message-ID: <87k1kd4tad.fsf@vitty.brq.redhat.com>
Date:   Thu, 13 Dec 2018 11:26:02 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Jim Mattson <jmattson@...gle.com>
Cc:     kvm list <kvm@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Roman Kagan <rkagan@...tuozzo.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "Michael Kelley \(EOSG\)" <Michael.H.Kelley@...rosoft.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Liran Alon <liran.alon@...cle.com>
Subject: Re: [PATCH v6 05/13] KVM: nVMX: implement enlightened VMPTRLD and VMCLEAR

Jim Mattson <jmattson@...gle.com> writes:

> On Tue, Oct 16, 2018 at 9:50 AM Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
>>
>> +
>> +               vmx->nested.hv_evmcs = kmap(vmx->nested.hv_evmcs_page);
>
> Are you sure that directly mapping guest memory isn't going to lead to
> time-of-check vs. time-of-use bugs? This is a very hard programming
> model to get right.

The basic assumption here is that Enlightened VMCS (just like normal or
shadow VMCSes) is being access by one L1 vCPU only. When we access it
from KVM the vCPU is not running. Yes, L1 guest can screw itself up by
breaking this assumption but honestly I don't see how this is different
from normal VMCS: we can always break things by writing to the page from
a different vCPU.

Enlightened VMCS is (mostly) not used directly: we copy it to vmcs12 and
then back before entry. The only field we always access directly is
hv_clean_fields. We can, of course, copy it to vmcs12 too but I failed
to find a reason to do so: L1 guest is in control of the field, it can
always write junk there and L2 guest will likely get broken.

I remember having map/copy/unmap sequences for eVMCS on entry/exit in
some early version of this series but it was just slowing things down so
I switched to having it permanently mapped. In case you see (potential)
grave bugs with this we can of course re-consider.

Thanks,

-- 
Vitaly