On 05/11/2019 00:25, Andrew Cooper wrote: > 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.
So, this is just another case of an issue I've already tried fixing once and haven't had time to fix in a way which doesn't break other pieces of functionality. I clearly need to dust off that series and get it working properly. In the short term, this will work around your problem. diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h index f86af09898..10daaa6f33 100644 --- a/xen/include/asm-x86/hvm/hvm.h +++ b/xen/include/asm-x86/hvm/hvm.h @@ -522,8 +522,7 @@ static inline void hvm_invlpg(struct vcpu *v, unsigned long linear) (X86_CR4_VMXE | X86_CR4_PAE | X86_CR4_MCE)) /* These exceptions must always be intercepted. */ -#define HVM_TRAP_MASK ((1U << TRAP_debug) | \ - (1U << TRAP_alignment_check) | \ +#define HVM_TRAP_MASK ((1U << TRAP_alignment_check) | \ (1U << TRAP_machine_check)) static inline int hvm_cpu_up(void) However, be aware that it will reintroduce http://xenbits.xen.org/xsa/advisory-156.html so isn't recommended for general use. Seeing as this looks to be some DRM software, it isn't likely to mount an attack like that, as it would livelock a native system just as badly as it livelocks a virtualised system. (Sadly, it looks like CVE-2015-8104 is the gift which keeps on giving us new corner cases in VT-x when it comes to the handling of debug exceptions. I've already found several acknowledged by Intel, and one which they are still trying to figure out how to fix.) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
