Re: [Xen-devel] [PATCH V5] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 02/23/2018 06:53 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojocaru@xxxxxxxxxxxxxxx]
>> Sent: Friday, February 16, 2018 6:22 PM
>>
>> The emulation layers of Xen lack PCID support, and as we only offer
>> PCID to HAP guests, all writes to CR3 are handled by hardware,
>> except when introspection is involved. Consequently, trying to set
>> CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
>> crashes. The workaround is to clear the noflush bit in
>> hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
>> Additionally, a bool parameter now propagates to
>> {svm,vmx}_update_guest_cr(), so that no flushes occur when
>> the bit was set.
> 
> Above message is not very clear for people who didn't follow
> previous discussions, e.g. why lacking PCID support in emulation 
> layer would lead to domain crash? and why noflush trick can 
> avoid the situation? Can you help elaborate it?

Lacking PCID support in the emulation layer creates two different way of
handling the NOFLUSH being set: one is in hardware, and this happens for
everything except the introspection case, and one in the emulation layer
(this happens when an introspection agent asks Xen to emulate an
instruction when it replies to an EPT fault vm_event).

The checks in place expected the guest state to be correct with regard
to handling the bit being set "the hardware way", but the emulation
layer was, previous to this patch, completely ignoring the NOFLUSH bit.
Hence, there was a difference between the expected domain state and the
actual domain state, which translated into a domain crash.

This patch does the work required by the NOFLUSH bit being set (i.e. it
avoids the flush when setting CR3), and then clears the bit ensuring
that the final state passes the Xen check.

> btw I didn't see any place setting the new macro 
> (X86_CR3_NOFLUSH). just check and clear.

Xen doesn't set it, the guest OS does.


Thanks,
Razvan

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