|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |