RE: [Xen-devel] privileged op emulation

["Altobelli, David" <david.altobelli@xxxxxx>]

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