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