[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Xen 4.11.1: guest uses altp2m to crash host



Greetings,

I've found a way to crash a host from a misbehaving guest, using altp2m. This is on a recent Intel core i7 chip. I've crashed two systems running 4.11.1. This behavior is not exhibited on 4.12, and since altp2m is a tech preview in 4.11.1, this is not covered by security support. However, I believe that the divergence between software and hardware state, as mentioned below, is still present in 4.12.

On Xen 4.11.1 with altp2m enabled, follow these steps in the guest, whose config file includes `altp2m = "mixed":
1. Allocate page P (GFN G)
2. Enable altp2m
3. Enable #VE notification, setting to G
4. Disable altp2m
5. Enable altp2m
6. Enable #VE notification, setting to G

At this point the entire system is unresponsive; #6 does not return control to the guest. Note that step 3 is required, thus indicating some incomplete cleanup after 4 that leads to a crash at 6. I've noticed a problem in the Xen source at step 4, where the software and hardware states diverge. See below for my notes on pertinent code.

I hope this is helpful and would appreciate it if you could fill me in on why the entire host goes down - I suspect Xen is interacting with the VMCS incorrectly, but I don't know the details and would like to understand.

1. Allocate page P (GFN G)

2. HVMOP_altp2m_set_domain_state(true)
    set d->arch.altp2m_active = true
    if first time:
       p2m_init_altp2m_by_id()
    for each vcpu V:
       altp2m_vcpu_initialise(V)
          reset (av->p2midx = INVALID_ALTP2M,
                 av->veinfo_gfn = INVALID_GFN)
          altp2m_vcpu_update_p2m(V)

3. HVMOP_altp2m_vcpu_enable_notify(G)
     checks: only toggling between INVALID_GFN and another value is permitted
     set vcpu_altp2m(curr).veinfo_gfn = G
     altp2m_vcpu_update_vmfunc_ve()

4. HVMOP_altp2m_set_domain_state(false)
     set d->arch.altp2m_active = false
     for each vcpu V:
        altp2m_vcpu_destroy()
          reset (av->p2midx = INVALID_ALTP2M,
                 av->veinfo_gfn = INVALID_GFN)
          altp2m_vcpu_update_p2m(V)
              ****** Does not update VMCS because altp2m_active() evals to false *****

Now the software (Xen) thinks altp2m is disabled, but the hardware has these features registered/enabled:
   VM_FUNCTION_CONTROL
   EPTP_LIST_ADDR
   VIRT_EXCEPTION_INFO

5. HVMOP_altp2m_set_domain_state(true)
      see above

6. HVMOP_altp2m_vcpu_enable_notify(not INVALID_GFN):
     checks: only toggling between INVALID_GFN and another value is permitted
       -succeeds because reset() was called above
     set vcpu_altp2m(curr).veinfo_gfn = G
     altp2m_vcpu_update_vmfunc_ve()

I claim that something in step 6 causes an unhandled exception. Please note that the guest does not register a #VE ISR.

Kind regards,
Matt Leinhos
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.