x86/svm: Fix a livelock when trying to run shadowed unpaged guests

On AMD processors which support SMEP (Some Fam16h processors) and SMAP (Zen,
Fam17h), a guest which is running with shadow paging and clears CR0.PG while
keeping CR4.{SMEP,SMAP} set will livelock, as hardware raises #PF which the
shadow pagetable concludes shouldn't happen.

This occurs because hardware is running with host paging settings, which
causes the guests choice of SMEP/SMAP to actually take effect, even though
they shouldn't from the guests point of view.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
This commit is contained in:
Andrew Cooper committed 2017-10-02 13:57:34 +01:00
1 parent ceb6ad8850
commit 3164f2f9db
1 file changed
+18
+18
View File
@@ -576,6 +576,24 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
if ( paging_mode_hap(v->domain) )
value &= ~X86_CR4_PAE;
value |= v->arch.hvm_vcpu.guest_cr[4];
if ( !hvm_paging_enabled(v) )
{
/*
* When the guest thinks paging is disabled, Xen may need to hide
* the effects of shadow paging, as hardware runs with the host
* paging settings, rather than the guests settings.
*
* Without CR0.PG, all memory accesses are user mode, so
* _PAGE_USER must be set in the shadow pagetables for guest
* userspace to function. This in turn trips up guest supervisor
* mode if SMEP/SMAP are left active in context. They wouldn't
* have any effect if paging was actually disabled, so hide them
* behind the back of the guest.
*/
value &= ~(X86_CR4_SMEP | X86_CR4_SMAP);
}
vmcb_set_cr4(vmcb, value);
break;
default:
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.