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