Hey Keir, DTRACE in linux/solaris guests use invalid op code sequence: opcode trap is: 0xF0 0x90 0x90 0x90 0x90 (LOCK NOP NOP NOP NOP) to receive UD, but they get GPF instead. (xen 4.1.2) Looking at hvm_emulate_one() I see place where it generates GPF if not expected sequence. Do you know quickly what can be done to deliver UD for the above sequence, or what single byte they can use to generate UD? (int 6 is two byte instr and doesn''t work for them). thanks a lot, Mukesh
On 23/03/12 18:44, Mukesh Rathor wrote:> Hey Keir, > > DTRACE in linux/solaris guests use invalid op code sequence: > > opcode trap is: 0xF0 0x90 0x90 0x90 0x90 (LOCK NOP NOP NOP NOP) > > to receive UD, but they get GPF instead. (xen 4.1.2) > > Looking at hvm_emulate_one() I see place where it generates GPF if not > expected sequence. Do you know quickly what can be done to deliver UD > for the above sequence, or what single byte they can use to generate > UD? (int 6 is two byte instr and doesn''t work for them). > > thanks a lot, > MukeshThere is the UD2 instruction 0x0F 0x0B which is specifically designed to cause a #UD exception. I am not sure what you mean by "single byte", as the example sequence is not a single byte instruction. The LOCK is an instruction prefix, making the first NOP a 2 byte instruction, followed by three 1byte instructions. As for the operation of LOCK NOP, Intel manual 2B defines this to cause an #UD exception, so that is a bug in Xen. It has been long time since I have played about in that code - I will see if I can remember enough to fix this issue, but others will probably be faster. ~Andrew> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On 23/03/2012 18:44, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:> Hey Keir, > > DTRACE in linux/solaris guests use invalid op code sequence: > > opcode trap is: 0xF0 0x90 0x90 0x90 0x90 (LOCK NOP NOP NOP NOP) > > to receive UD, but they get GPF instead. (xen 4.1.2) > > Looking at hvm_emulate_one() I see place where it generates GPF if not > expected sequence. Do you know quickly what can be done to deliver UD > for the above sequence, or what single byte they can use to generate > UD? (int 6 is two byte instr and doesn''t work for them).You''ll have to point out the path taken. AFAICS the sequence will cause a #UD trap into Xen, which will execute vmx_vmexit_ud_intercept(), should get X86EMUL_UNHANDLEABLE from hvm_emulate_one() and then inject the #UD back up into the guest. I don''t see where the #GP would come from: certainly hvm_emulate_one() itself doesn''t appear to generate any guest exceptions. Is it coming from the emulator itself? Might be a bug to be fixed if so. -- Keir> thanks a lot, > Mukesh
Patch attached. Not tested, but seems logically correct. @Mukesh: Do you mind testing please? -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, 23 Mar 2012 19:17:47 +0000 Keir Fraser <keir.xen@gmail.com> wrote:> You''ll have to point out the path taken. AFAICS the sequence willOk, I can do that and let you know.>I don''t see where the #GP would come from: certainly hvm_emulate_one()It may be coming from: x86_emulate(): * The only implicit-operands instructions allowed a LOCK prefix are * CMPXCHG{8,16}B, MOV CRn, MOV DRn. */ generate_exception_if( lock_prefix && ((b < 0x20) || (b > 0x23)) && /* MOV CRn/DRn */ (b != 0xc7), /* CMPXCHG{8,16}B */ EXC_GP, 0); thanks, Mukesh
On Fri, 23 Mar 2012 19:20:58 +0000 Andrew Cooper <andrew.cooper3@citrix.com> wrote:> Patch attached. > > Not tested, but seems logically correct. > > @Mukesh: Do you mind testing please? >Sure. Let me build xen with fix and give to Dtrace developers. thanks, Mueksh
On 23/03/12 19:30, Mukesh Rathor wrote:> On Fri, 23 Mar 2012 19:20:58 +0000 > Andrew Cooper <andrew.cooper3@citrix.com> wrote: > >> Patch attached. >> >> Not tested, but seems logically correct. >> >> @Mukesh: Do you mind testing please? >> > Sure. Let me build xen with fix and give to Dtrace developers. > > thanks, > MuekshSadly, given your other email, I doubt it will work, because of the big catch all regarding the lock prefix. A brief scan over the Intel manuals and I cant see a case where an incorrect LOCK prefix would cause #GPF rather than #UD. Perhaps try changing it to EXP_UD instead of EXP_GP. (Although I make no guarantee that this wont cause a lot of things to break.) -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On 23/03/12 19:38, Andrew Cooper wrote:> Sadly, given your other email, I doubt it will work, because of the big > catch all regarding the lock prefix. > > A brief scan over the Intel manuals and I cant see a case where an > incorrect LOCK prefix would cause #GPF rather than #UD. > > Perhaps try changing it to EXP_UD instead of EXP_GP. (Although I make > no guarantee that this wont cause a lot of things to break.)Try this patch instead. I have still yet to find a single example in either manual 2A or B where an invalid lock prefix would cause a #GPF rather than #UD -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 23/03/2012 19:58, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:> On 23/03/12 19:38, Andrew Cooper wrote: >> Sadly, given your other email, I doubt it will work, because of the big >> catch all regarding the lock prefix. >> >> A brief scan over the Intel manuals and I cant see a case where an >> incorrect LOCK prefix would cause #GPF rather than #UD. >> >> Perhaps try changing it to EXP_UD instead of EXP_GP. (Although I make >> no guarantee that this wont cause a lot of things to break.) > > Try this patch instead. > > I have still yet to find a single example in either manual 2A or B where > an invalid lock prefix would cause a #GPF rather than #UDYeah, this is a good fix. The origin of #GP is way back when I was doing a major weekend hack on extending the emulator for vmx realmode emulation. I expect in haste I picked the wrong exception type and that has propagated onward. I will apply to xen-unstable, and if it seems okay theer it can be backported for 4.1 and 4.0. -- Keir