Failed vm entry when emulating in hvm_do_resume()

Failed vm entry when emulating in hvm_do_resume()

[Razvan Cojocaru]

Hello,

As a test, I've modified xen-access.c to this simplified skeleton:

http://pastebin.com/48WYwW00

then started up an x86 Windows 7 HVM guest, and ran it with:

# ./xen-access <dom_id> write

once the login screen appeared. The guest promptly crashed with this
backtrace:

http://pastebin.com/Bz0GeFta

The modified xen-access.c simply removes write rights for all of the
guest's pages, then attempts to emulate all instructions that might
cause a page fault. While I didn't expect the guest to run in a useable
manner, or Xen to be able to emulate all the instructions, I did not
expect the guest to crash.

So it would seem that hvm_do_resume() is, after all, not the best place
to emulate after a vm_event reply asks for emulation.

It's also not clear if (since in entry.S vmx_intr_assist() is being
called very early) we might not be, instead of right where we left off
on the VPCU when we sent out the mem_access vm_event, in an interrupt
handler (where emulating the first instruction is not good).

Could someone please recommend a safe place to try to emulate if
hvm_do_resume() is problematic?

Should I go back to the comparably inefficient way we did it before
(emulate on the second page fault where the RIP and GPA match)?
That indeed seems to offer no surprise crashes, but has the
aforementioned efficiency drawback, coupled with the fact that an
interrupt can cause the EIP and GPA to differ, in which case it would
take 4 page faults to finally emulate an offending instruction and
proceed. I did try the previous access_check() solution, and in addition
returning from vmx_intr_assist() (like the single stepping code does) if
there's an emulation request pending:

222 void vmx_intr_assist(void)
223 {
224     struct hvm_intack intack;
225     struct vcpu *v = current;
226     unsigned int tpr_threshold = 0;
227     enum hvm_intblk intblk;
228     int pt_vector = -1;
229
230     /* Block event injection when an instruction emulation is
pending. */
231     if ( unlikely(v->arch.vm_event) && v->arch.vm_event->emulate_flags )
232         return;

However that seems to trigger occassional BSODs related to clock
interrupts: http://i.imgur.com/EEz3JBV.png


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Failed vm entry when emulating in hvm_do_resume()

[Andrew Cooper]

On 04/04/16 14:32, Razvan Cojocaru wrote:
> Hello,
>
> As a test, I've modified xen-access.c to this simplified skeleton:
>
> http://pastebin.com/48WYwW00
>
> then started up an x86 Windows 7 HVM guest, and ran it with:
>
> # ./xen-access <dom_id> write
>
> once the login screen appeared. The guest promptly crashed with this
> backtrace:
>
> http://pastebin.com/Bz0GeFta
>
> The modified xen-access.c simply removes write rights for all of the
> guest's pages, then attempts to emulate all instructions that might
> cause a page fault. While I didn't expect the guest to run in a useable
> manner, or Xen to be able to emulate all the instructions, I did not
> expect the guest to crash.

This is just a plain emulation bug in 'cli', and has already been
reported on the list.  Noone has addressed the issue yet.

The vmentry failure will be eflags not matching up with some other vmcs
state.  Looks like you have valid VMEntry intr_info injecting vector
0xd1, and eflags.IF disabled.  This smells like a bug when considering
whether to inject the next pending interrupt from the lapic.

The reason you are seeing this with introspection is because you are the
first people to test these codepaths.  Normally, there is no way a 'cli'
instruction could fault for emulation, because it has no memory operand.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel