Re: [Xen-devel] [BUG] Invalid guest state in Xen master, dom0 linux-5.3.6, domU windows 10

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel