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

[Håkon Alstadheim <hakon@xxxxxxxxxxxxxxxxxx>]

Den 05.11.2019 02:15, skrev Andrew Cooper:
> 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.
Thank you kindly. Ever the optimist, I'll apply the patch.
> 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.
I'm slightly relieved the malware running on my system is courtesy of 
big media rather than some Romanian consultant for the RNC.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel