WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] privileged op emulation

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] privileged op emulation
From: "Altobelli, David" <david.altobelli@xxxxxx>
Date: Fri, 2 Jun 2006 10:33:34 -0500
Delivery-date: Fri, 02 Jun 2006 08:34:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0BA7FCDA@xxxxxxxxxxxxxxxxx>
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: AcaGVcirZkmiH66VSJWdIi8egxxUqQAAG1UQAADFIOA=
Thread-topic: [Xen-devel] privileged op emulation
> -----Original Message-----
> From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx] 
> Sent: Friday, June 02, 2006 10:14 AM
> To: Altobelli, David; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] privileged op emulation
> 
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Altobelli, 
> > David
> > Sent: 02 June 2006 16:04
> > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [Xen-devel] privileged op emulation
> > 
> > I'm new to this list, so please forgive me if this has already been 
> > discussed or I'm way off target.
> > 
> > I am interested in how the XEN hypervisor handles privileged ops,
> > specifically on x86 platforms.    
> > 
> > Looking at emulate_privileged_op(), called from
> > do_general_protection() [xen/arch/x86/traps.c], I think there is a 
> > problem with how instructions are emulated. Assuming all permission 
> > checks pass, the instruction is emulated.  But it is 
> emulated with XEN 
> > hypervisor context.  I believe it needs to be emulated with 
> the user's 
> > context in place.  I'm not saying XEN gets the wrong answer for the 
> > specific instruction (I'm worried about "out"), I'm saying 
> that this 
> > instruction might have side effects, and therefore the 
> user's context 
> > needs to be restored in registers before this instruction 
> is executed.  
> > I believe XEN needs to validate the op, then restore the users 
> > context, run the instruction, and iret to the user, without 
> modifying 
> > any registers in between the instruction and the iret.
> 
> Are you in this particular case thinking of "weird" side 
> effects like the OUT instruction is actually causing a SMI, 
> in which the user-registers are being used for arguments?

Yes, that's exactly the case I'm thinking about.  I have a userspace
application that basically does:
iopl()
...
Setup registers
cli
out -> trigger SMI which looks at registers
...

> 
> In any other case, I can't see what the OTHER registers have 
> as content should make any difference whatsoever. 
> 
> If you are looking at SMI-sideeffects, then I would expect 
> the code to be likely to break in many other aspects as well. 
> 
> Note that emulate_privileged_op() is only emulating special 
> instructions that are done inside the OS-kernel (because the 
> kernel runs at Ring1, so the kernel isn't allowed to touch 
> for example CR0, I/O ports (unless the specific bits in 
> TSS->IOPLMAP is set to allow it, of course). And for a 
> Xenified kernel, the operations are well-known and we have 
> the source code to look at for each case of those 
> instructions to inspect if there's any further need to do something. 
> 
> I'm not saying you're wrong (the opposite - you have a valid 
> point), but at the same time, the existing code works 
> perfectly fine for the limited environment that it is 
> currently being used in. If it works, don't try to fix it... 
> 
> --
> Mats
> 
> 
> > 
> > Thanks,
> > dave
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> > 
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>