From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: List of unaccessible x86 states Date: Mon, 26 Oct 2009 10:33:48 +0200 Message-ID: <4AE55EEC.1060303@redhat.com> References: <4ADDB49B.3010101@siemens.com> <5D3F39A4-0532-4027-8D71-87FE9BCA1C27@suse.de> <4ADDBD19.6040107@siemens.com> <20091020134811.GO29477@redhat.com> <20091020185501.GD8278@redhat.com> <32ACB0C3-1607-4D4F-A085-25D1AA1FB255@suse.de> <20091020190958.GE8278@redhat.com> <4AE41E5B.7080406@redhat.com> <761AD9DC-7CCA-4AEC-BD5E-687E718BF899@suse.de> <4AE45BCD.5040305@redhat.com> <958C1AC1-505B-4467-A2FC-D9BA4A2F2737@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Jan Kiszka , "oritw@il.ibm.com" , kvm-devel , Marcelo Tosatti To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50880 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754545AbZJZIdw (ORCPT ); Mon, 26 Oct 2009 04:33:52 -0400 In-Reply-To: <958C1AC1-505B-4467-A2FC-D9BA4A2F2737@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 10/25/2009 06:45 PM, Alexander Graf wrote: >>> It's not. We can't use the guest memory for hsave because then the >>> guest could break the l1 state, so a malicious hypervisor could >>> break us. >> >> Guest hsave should be used for storing guest state when switching >> into the nested guest, not host state. Host state is not part of the >> save/restore state in any case. > > > No it's not. > > When going in an l2 guest, we need to save the l1 state in the hsave. > Now if we'd use the l1 given hsave, the l2 guest could modify the hsave. > > That means the l2 guest could rewrite the intercept bitmap to 0 and > compromize the host. L1 hsave stores the architected state saved by vmrun, e.g. cs.sel, next_rip, cr0, cr3, etc. The host intercept bitmap is not state since it is calculated from the L1 intercept bitmap and host code. Indeed it can be different from host to host even with the same guest state. > That's why we're storing the hsave data in a host allocated page. > > Of course, we could save the whole hsave are off to the host on > migeation... Sorry, -ENOPARSE. -- error compiling committee.c: too many arguments to function