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: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] svm: save_svm_cpu_user_regs vs. svm_store_cpu_guest_regs
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 09 May 2007 09:34:31 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 09 May 2007 01:31:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46419E40.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceSFN0cG5/1mv4IEdu9MQAWy6hiGQ==
Thread-topic: [Xen-devel] svm: save_svm_cpu_user_regs vs. svm_store_cpu_guest_regs
User-agent: Microsoft-Entourage/
On 9/5/07 09:11, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> 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 rAX that is saved on the stack in exits.S is not the guest rAX. It's a
bogus value which gets overwritten by save_svm_cpu_user_regs().

The fact that the rAX value then gets stuffed back into VMCB in exits.S on
vmentry is pretty disgusting. We should move the rAX loading on vmexit into
exits.S as well for symmetry, and kill save_svm_cpu_user_regs().

> 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:

Okay then, more precisely: modulo bugs it can be removed. Or we load/save
all VMCB state into the regs structure in exits.S, increasing latency
slightly for all vmexits but avoiding any risk of inconsistent 'struct regs'

 -- Keir

> If I'm seeing things right (I didn't check this on hardware, yet), hvm
> hypercalls
> 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