This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] svm: save_svm_cpu_user_regs vs. svm_store_cpu_guest_regs

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] svm: save_svm_cpu_user_regs vs. svm_store_cpu_guest_regs
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 09 May 2007 10:11:12 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 09 May 2007 01:08:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2673C00.704A%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4641938C.76E4.0078.0@xxxxxxxxxx> <C2673C00.704A%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 09.05.07 09:51 >>>
>On 9/5/07 08:25, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> What is the reason for save_svm_cpu_user_regs() explicitly saving rax?
>> Without this, the function could be eliminated, with its single use replaced
>> by a call to svm_store_cpu_guest_regs().
>It would be great if we can get away with just moving save/restore of rAX
>into svm_{load,store}_cpu_guest_regs(), kill save_svm_cpu_user_regs()
>completely, and get rid of the call at the top of the vmexit handler.
>There's no equivalent call at the top of the VMX vmexit handler: all the
>common HVM code will explicitly svm_store_cpu_guest_regs() before depending
>on GPR state.

It's not really GPR state that matters here (GPRs are saved in the respective
exit.S files), which is why I wondered about the need for saving RAX. The point
here is that CS:RIP, RFLAGS, and SS:RSP may need to be stored, and the fact
that VMX doesn't do so doesn't mean it can be freely removed from SVM code:
If I'm seeing things right (I didn't check this on hardware, yet), hvm 
are currently having a security hole on VMX in that ring 3 code can possibly
invoke them and/or prevent ring 0 from invoking them - VMX code doesn't seem
to save the CS selector anywhere, but the ring_3() test depends on that (so
generally appears to operate on stale data, i.e. whatever was saved on the
stack the last time vmx_store_cpu_guest_regs() was executed. If I wasn't
buried in hunting bugs for SLE10 SP1, I would have confirmed this already and
sent a patch if necessary (along with quite a few more ones, more or less all
addressing 32on64/hvm weakness)...


Xen-devel mailing list