linux-kernel - Re: [PATCH] KVM: nVMX: Fix CR4 after VMLAUNCH/VMRESUME failure

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, 7 Feb 2018 08:57:09 -0800
From:   Jim Mattson <jmattson@...gle.com>
To:     Wanpeng Li <kernellwp@...il.com>
Cc:     kvm list <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Radim Krcmar <rkrcmar@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH] KVM: nVMX: Fix CR4 after VMLAUNCH/VMRESUME failure

vmcs12->host_cr[34] does not contain the up-to-date values when L1 is
running. L1 can vmwrite any values there. We know at this point that
they are legal (because we checked them), but that's about it. If the
VMLAUNCH/VMRESUME of vmcs12 fails for "invalid control field," there
is no VM-exit from L2 to L1, and these fields are not loaded. Instead,
execution just falls through to the next instruction with VMFailValid
semantics.

On Wed, Feb 7, 2018 at 12:31 AM, Wanpeng Li <kernellwp@...il.com> wrote:
> 2018-02-07 0:58 GMT+08:00 Jim Mattson <jmattson@...gle.com>:
>> On Mon, Feb 5, 2018 at 4:57 PM, Wanpeng Li <kernellwp@...il.com> wrote:
>>
>>> This is effective one, what I restore in this patch is
>>> achitectural/guest visible.
>>
>> This patch doesn't "restore" the guest visible CR4 to its value at the
>> time of VMLAUNCH/VMRESUME. It loads a new CR4 value from the vmcs12.
>> That behavior is incorrect.
>
> You have another pointing out about this.
> https://lkml.org/lkml/2018/2/5/518 vmcs12->host_cr3/host_cr4 has the
> up-to-date value when L1 is running, it is still up-to-date after
> vmexit due to L1 executes VMLAUNCH/VMRESUME, I think the value stays
> the same before L0 emulates the VMLAUNCH/VMRESUME, according to below
> comments, why vmcs12->host_cr3/cr4 is not the value which we should
> restore?
>
> * After an early L2 VM-entry failure, we're now back
> * in L1 which thinks it just finished a VMLAUNCH or
> * VMRESUME instruction
>
> Regards,
> Wanpeng Li