Re: [Xen-devel] [v8][PATCH 12/17] xen/x86/ept: handle reserved device memory in ept_handle_violation

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:25 PM
> 
> We always reserve these ranges since we never allow any stuff to
> poke them.
> 
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since other OSs may touch them
> by careless behavior, so its enough to have a lightweight way, and
> it shouldn't be same as those broken pages which cause domain crush.
> 
> So we just need to return with next eip then let VM/OS itself handle
> such a scenario as its own logic.
> 
> Signed-off-by: Tiejun Chen <tiejun.chen@xxxxxxxxx>
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2907afa..3ee884a 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2403,6 +2403,7 @@ static void ept_handle_violation(unsigned long
> qualification, paddr_t gpa)
>      p2m_type_t p2mt;
>      int ret;
>      struct domain *d = current->domain;
> +    struct p2m_get_reserved_device_memory pgrdm;
> 
>      /*
>       * We treat all write violations also as read violations.
> @@ -2438,6 +2439,23 @@ static void ept_handle_violation(unsigned long
> qualification, paddr_t gpa)
>          __trace_var(TRC_HVM_NPF, 0, sizeof(_d), &_d);
>      }
> 
> +    /* This means some untrusted VM can maliciously access reserved
> +     * device memory. But we just don't want to leak anything or
> +     * introduce any side affect since other OSs may touch them by
> +     * careless behavior, so its enough to have a lightweight way.
> +     * Here we just need to return with next eip then let VM/OS itself
> +     * handle such a scenario as its own logic.
> +     */
> +    pgrdm.gfn = gfn;
> +    pgrdm.domain = d;
> +    ret =
> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> +                                           &pgrdm);

can this be optimized to not walk rmrr map if no device is assigned?

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