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

[Xen-devel] [v7][RFC][PATCH 09/13] xen/x86/ept: handle reserved device memory in ept_handle_violation



We always initialize all reserved device memory as p2m_access_n in
case of shared-ept or non-shared-ept but 1:1 mapping, and we only
allow to reset these tables if assign a device with reserved device
memory. So if others try to access we just update eip then return.

Signed-off-by: Tiejun Chen <tiejun.chen@xxxxxxxxx>
---
 xen/arch/x86/hvm/vmx/vmx.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 304aeea..5efec93 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2398,6 +2398,20 @@ static void ept_handle_violation(unsigned long 
qualification, paddr_t gpa)
         __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
     }
 
+    /* If this violation is from reserved device memory range
+     * this means something may maliciously access them since
+     * we always initialize these tables as p2m_access_n unless
+     * in case of device assignment.
+     * So its not allowed then we just update eip then return.
+     */
+    ret = iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
+                                           &gfn);
+    if ( ret )
+    {
+        update_guest_eip();
+        return;
+    }
+
     if ( qualification & EPT_GLA_VALID )
     {
         __vmread(GUEST_LINEAR_ADDRESS, &gla);
-- 
1.9.1


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


 


Rackspace

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