[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 |