linux-kernel - RE: [PATCH v3] xen: support priv-mapping in an HVM tools domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2247ffb2884a458b9e756ae990cc3f7c@AMSPEX02CL03.citrite.net>
Date:   Fri, 3 Nov 2017 16:59:35 +0000
From:   Paul Durrant <Paul.Durrant@...rix.com>
To:     Paul Durrant <Paul.Durrant@...rix.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: RE: [PATCH v3] xen: support priv-mapping in an HVM tools domain

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@...rix.com]
> Sent: 03 November 2017 16:58
> To: x86@...nel.org; xen-devel@...ts.xenproject.org; linux-
> kernel@...r.kernel.org
> Cc: Paul Durrant <Paul.Durrant@...rix.com>; Boris Ostrovsky
> <boris.ostrovsky@...cle.com>; Juergen Gross <jgross@...e.com>; Thomas
> Gleixner <tglx@...utronix.de>; Ingo Molnar <mingo@...hat.com>; H. Peter
> Anvin <hpa@...or.com>
> Subject: [PATCH v3] xen: support priv-mapping in an HVM tools domain
> 
> If the domain has XENFEAT_auto_translated_physmap then use of the PV-
> specific HYPERVISOR_mmu_update hypercall is clearly incorrect.
> 
> This patch adds checks in xen_remap_domain_gfn_array() and
> xen_unmap_domain_gfn_array() which call through to the approprate
> xlate_mmu function if the feature is present.
> 
> This patch also moves xen_remap_domain_gfn_range() into the PV-only
> MMU
> code and #ifdefs the (only) calling code in privcmd accordingly.

<sigh> I realise now that this paragraph refers to the code in the v2 patch. I'll send v4.

  Paul

> 
> Signed-off-by: Paul Durrant <paul.durrant@...rix.com>
> ---
> Cc: Boris Ostrovsky <boris.ostrovsky@...cle.com>
> Cc: Juergen Gross <jgross@...e.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> 
> v3:
>  - As v1 but with additional stubs in xen/xen-ops.h to handle
>    configurations without CONFIG_XEN_AUTO_XLATE.
> ---
>  arch/x86/xen/mmu.c    | 14 ++++++++++++--
>  include/xen/xen-ops.h | 24 ++++++++++++++++++++++++
>  2 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 3e15345abfe7..d33e7dbe3129 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -172,6 +172,9 @@ int xen_remap_domain_gfn_range(struct
> vm_area_struct *vma,
>  			       pgprot_t prot, unsigned domid,
>  			       struct page **pages)
>  {
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return -EOPNOTSUPP;
> +
>  	return do_remap_gfn(vma, addr, &gfn, nr, NULL, prot, domid,
> pages);
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
> @@ -182,6 +185,10 @@ int xen_remap_domain_gfn_array(struct
> vm_area_struct *vma,
>  			       int *err_ptr, pgprot_t prot,
>  			       unsigned domid, struct page **pages)
>  {
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return xen_xlate_remap_gfn_array(vma, addr, gfn, nr,
> err_ptr,
> +						 prot, domid, pages);
> +
>  	/* We BUG_ON because it's a programmer error to pass a NULL
> err_ptr,
>  	 * and the consequences later is quite hard to detect what the actual
>  	 * cause of "wrong memory was mapped in".
> @@ -193,9 +200,12 @@
> EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array);
> 
>  /* Returns: 0 success */
>  int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> -			       int numpgs, struct page **pages)
> +			       int nr, struct page **pages)
>  {
> -	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return xen_xlate_unmap_gfn_range(vma, nr, pages);
> +
> +	if (!pages)
>  		return 0;
> 
>  	return -EINVAL;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 218e6aae5433..18b25631a113 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -103,6 +103,8 @@ int xen_remap_domain_gfn_range(struct
> vm_area_struct *vma,
>  			       struct page **pages);
>  int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>  			       int numpgs, struct page **pages);
> +
> +#ifdef CONFIG_XEN_AUTO_XLATE
>  int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>  			      unsigned long addr,
>  			      xen_pfn_t *gfn, int nr,
> @@ -111,6 +113,28 @@ int xen_xlate_remap_gfn_array(struct
> vm_area_struct *vma,
>  			      struct page **pages);
>  int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
>  			      int nr, struct page **pages);
> +#else
> +/*
> + * These two functions are called from arch/x86/xen/mmu.c and so stubs
> + * are needed for a configuration not specifying
> CONFIG_XEN_AUTO_XLATE.
> + */
> +static inline int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> +					    unsigned long addr,
> +					    xen_pfn_t *gfn, int nr,
> +					    int *err_ptr, pgprot_t prot,
> +					    unsigned int domid,
> +					    struct page **pages)
> +{
> +	return -EOPNOTSUPP;
> +}
> +
> +static inline int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
> +					    int nr, struct page **pages)
> +{
> +	return -EOPNOTSUPP;
> +}
> +#endif
> +
>  int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
>  				  unsigned long nr_grant_frames);
> 
> --
> 2.11.0