On 04/11/2019 23:42, Andrew Cooper wrote: > On 04/11/2019 23:20, Håkon Alstadheim wrote: >> (XEN) RFLAGS=0x00000193 (0x00000193) DR7 = 0x0000000000000400 >> <snip> >> (XEN) *** Insn bytes from ffffb8868f61d69a: 44 00 00 8c d0 9c 81 0c 24 >> 00 01 00 00 9d 8e d0 <fffffff1> 9c 81 24 24 ff fe ff ff 9d c3 cc cc cc >> cc cc > Ok. One question answered, several more WTF. > > 0000000000000000 <.data>: > 0: 44 00 00 add %r8b,(%rax) > 3: 8c d0 mov %ss,%eax > 5: 9c pushfq > 6: 81 0c 24 00 01 00 00 orl $0x100,(%rsp) > d: 9d popfq > e: 8e d0 mov %eax,%ss > 10: f1 icebp > 11: 9c pushfq > 12: 81 24 24 ff fe ff ff andl $0xfffffeff,(%rsp) > 19: 9d popfq > 1a: c3 retq > 1b: cc int3 > 1c: cc int3 > 1d: cc int3 > 1e: cc int3 > 1f: cc int3 > > > This is a serious exercising of architectural corner cases, by layering > a single step exception on top of a MovSS-deferred ICEBP. > > Now I've looked closer, this isn't a CVE-2018-8897 exploit as no > breakpoints are configured in %dr7, so I'm going to revise my guess some > new debugger-detection in DRM software.
I've reproduced the VMEntry failure you were seeing. Now to figure out if there is sufficient control available to provide architectural behaviour to guest, because I'm not entirely certain there is, given some of ICEBP's extra magic properties. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
