linux-kernel - Re: [PATCH 4/4] KVM: nVMX: initialize more non-shadowed fields in prepare_vmcs02

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: <66175f1a-ba57-f08b-5ba7-e4fe42f14f7a@redhat.com>
Date:   Wed, 27 Dec 2017 10:54:24 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Wanpeng Li <kernellwp@...il.com>
Cc:     linux-kernel@...r.kernel.org, kvm <kvm@...r.kernel.org>
Subject: Re: [PATCH 4/4] KVM: nVMX: initialize more non-shadowed fields in
 prepare_vmcs02_full

On 25/12/2017 04:09, Wanpeng Li wrote:
> 2017-12-21 20:43 GMT+08:00 Paolo Bonzini <pbonzini@...hat.com>:
>> These fields are also simple copies of the data in the vmcs12 struct.
>> For some of them, prepare_vmcs02 was skipping the copy when the field
>> was unused.  In prepare_vmcs02_full, we copy them always as long as the
>> field exists on the host, because the corresponding execution control
>> might be one of the shadowed fields.
> 
> Why we don't need to copy them always before the patchset?

Before these patches, we only copy them if the corresponding processor
control is enabled.  For example, we only copy the EOI exit bitmap if
APICv is enabled by L1.  Here we could have

   write to EOI exit bitmap
   vmlaunch (calls prepare_vmcs02_full)
   enable APICv (but EOI exit bitmap fields are clean)
   vmresume (doesn't call prepare_vmcs02_full)

The vmresume doesn't call prepare_vmcs02_full, so the EOI exit bitmap
must be copied every time prepare_vmcs02_full runs.

Paolo