Re: UBSan bug in real mode fpu emulation

[Fabian Specht <f.specht@xxxxxx>]

> > if ( !s->rex_prefix )
> > {
> >     /* Convert 32-bit real/vm86 to 32-bit prot format. */
> >     unsigned int fip = fpstate.env.mode.real.fip_lo +
> >                                        (fpstate.env.mode.real.fip_hi << 16);
> >     unsigned int fdp = fpstate.env.mode.real.fdp_lo +
> >                                        (fpstate.env.mode.real.fdp_hi << 16);
> >     unsigned int fop = fpstate.env.mode.real.fop;
> >
> >     fpstate.env.mode.prot.fip = fip & 0xf;
> >     fpstate.env.mode.prot.fcs = fip >> 4;
> >     fpstate.env.mode.prot.fop = fop;
> >     fpstate.env.mode.prot.fdp = fdp & 0xf;
> >     fpstate.env.mode.prot.fds = fdp >> 4;
> > }

> Several things.  First, please always the UBSAN analysis from the crash.

(XEN) UBSAN: Undefined behaviour in arch/x86/x86_emulate/blk.c:87:66
(XEN) left shift of 65535 by 16 places cannot be represented in type 'int'
(XEN) ----[ Xen-4.20.0  x86_64  debug=y ubsan=y  Tainted:     H  ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82d04031fe8d>] 
common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd2
(XEN) RFLAGS: 0000000000010092   CONTEXT: hypervisor (d1v0)
(XEN) rax: 0000000000000000   rbx: ffff830176baf6c8   rcx: 00000000000004ce
(XEN) rdx: ffff830176baffd0   rsi: 0000000000000002   rdi: ffff830176baf6c8
(XEN) rbp: ffff830176baf660   rsp: ffff830176baf650   r8:  00000000ffffffff
(XEN) r9:  0000000000000000   r10: ffff830176baf670   r11: 0000000000000000
(XEN) r12: ffff82d040877992   r13: 0000000000000010   r14: 000000000000ffff
(XEN) r15: ffff82d040877992   cr0: 0000000080050033   cr4: 00000000003506e0
(XEN) cr3: 000000010089c000   cr2: 0000000000000000
(XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0033   gs: 0033   ss: 0000   cs: e008
(XEN) Xen code around <ffff82d04031fe8d> 
(common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd2):
(XEN)  89 e5 41 54 53 48 89 fb <0f> 0b 48 8d 3d 3a b6 36 00 e8 f3 95 00 00 48 85
(XEN) Xen stack trace from rsp=ffff830176baf650:
(XEN)    ffffffffffffffff ffff82d040877992 ffff830176baf6f8 ffff82d040320d8e
(XEN)    ffff82d0405603e3 ffff003533353536 ffff830176bafe10 ffff830176baf728
(XEN)    ffff82d04056076d ffff82e002017b00 0000000776003631 ffff830100882000
(XEN)    ffff830176baf770 0000000000000117 ffff830176baf778 0000000000000202
(XEN)    ffff830100bd8fd0 000000000000ffff 000000000000001c 00000000ffffffff
(XEN)    000000000000ffff ffff830176baf7b8 ffff82d04053c6a0 ffff830176bafce8
(XEN)    0000000000117fd0 0000000000000001 ffffffff76bafe08 ffffffffffffffff
(XEN)    ffffffffffffffff ffffffffffffffff ffff830176baf770 0000000100000001
(XEN)    ffff83010095b000 0000000000000001 0000000000117fd0 0000000076bafd68
(XEN)    ffff82e002017b00 0000000000117fd0 0000000300000003 0000000000000117
(XEN)    0000000000000001 000000000000001c ffff830100bd8fd0 ffff830176bafce8
(XEN)    ffff830176bafaa0 ffff830176baf808 ffff82d0404176a8 ffff830176bafba8
(XEN)    0000000000000000 0000000000117fd0 ffff830176bafce8 ffff830176bafaa0
(XEN)    ffff82d0404175e8 ffff830176bafa30 000000000000001c ffff830176baf880
(XEN)    ffff82d040545817 ffff830176bafce8 ffff830100000000 ffff82d07fffc140
(XEN)    ffff830176bafb18 ffff830176bafba8 ffff830100000080 0000000000010010
(XEN)    ffff83010000000b 0000000000000001 ffff830176bafef8 0000000000000000
(XEN)    ffff8301795d0010 0000000000000000 ffff830176bafc10 ffff82d0405e8400
(XEN)    ffff830176bafa9c ffff830176bafa24 ffff830176baf9c0 0000000000000000
(XEN)    0000000000000000 ffff830176bafc30 ffff82d0405d8d6b ffff830176baf968
(XEN) Xen call trace:
(XEN)    [<ffff82d04031fe8d>] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd2
(XEN)    [<ffff82d040320d8e>] F __ubsan_handle_shift_out_of_bounds+0x11c/0x1d1
(XEN)    [<ffff82d04053c6a0>] F x86_emul_blk+0x3d8/0x117d
(XEN)    [<ffff82d0404176a8>] F arch/x86/hvm/emulate.c#hvmemul_blk+0xc0/0x138
(XEN)    [<ffff82d040545817>] F x86emul_fpu+0x207e/0x819b
(XEN)    [<ffff82d0405e8400>] F x86_emulate+0x1527b/0x3ecb3
(XEN)    [<ffff82d040615d2a>] F x86_emulate_wrapper+0x87/0x216
(XEN)    [<ffff82d040418c41>] F 
arch/x86/hvm/emulate.c#_hvm_emulate_one+0x256/0x60f
(XEN)    [<ffff82d04041900c>] F hvm_emulate_one+0x12/0x14
(XEN)    [<ffff82d04042d239>] F hvm_ud_intercept+0x1e7/0x4c1
(XEN)    [<ffff82d0403dbd90>] F svm_vmexit_handler+0x1bc1/0x2d70
(XEN)    [<ffff82d040203540>] F svm_stgi_label+0x5/0x15
(XEN) 

> There are several different ways that shifts go wrong, and I suspect
> this is a shift into a sign bit, which is notable given the unsigned
> underlying type.

Might be, but I am not entirely sure. Either way, it should be fixed
through a simple cast to unsigned int I think.

> Also, are you aware that the test isn't properly in Real Mode?  It's in
> so-called unreal mode (not actually a real mode, but a consequence of
> how the segment registers work), which is relevant to how you manage to
> re-enter the emulator for FLDENV.

Yes I am aware. But the bug should be triggered regardless of the
current mode, right?

~Fabian