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. Thanks, dave _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Altobelli, David > Sent: 02 June 2006 16:04 > To: xen-devel@lists.xensource.com > 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? 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@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2 Jun 2006, at 16:04, Altobelli, David wrote:> 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.Please give a specific example which the current code emulates incorrectly. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Petersson, Mats [mailto:Mats.Petersson@amd.com] > Sent: Friday, June 02, 2006 10:14 AM > To: Altobelli, David; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] privileged op emulation > > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com > > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Altobelli, > > David > > Sent: 02 June 2006 16:04 > > To: xen-devel@lists.xensource.com > > 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
[snip]> > 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 ... >I think the CORRECT way to solve this is to have a particular port(set) (administered by the system administrator in the form of a command-line parameter to the Xen kernel perhaps) be allowed as "direct access" from the user-mode kernel, so that you get the correct behaviour. Most anything else would be somewhat wrong in one way or another [stack-pointer, instruction pointer at the very least would be wrong]. -- Mats _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel