Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 14 Sep 2018 10:12:22 -0700
From:   Eduardo Valentin <eduval@amazon.com>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC:     <linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>,
        Juergen Gross <jgross@suse.com>,
        Jan Beulich <jbeulich@suse.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH 4.14 103/115] x86/xen: dont write ptes directly in 32-bit
 PV guests
Message-ID: <20180914171222.GA30580@u40b0340c692b58f6553c.ant.amazon.com>
References: <20180913131823.327472833@linuxfoundation.org>
 <20180913131829.701763608@linuxfoundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180913131829.701763608@linuxfoundation.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello,

On Thu, Sep 13, 2018 at 03:32:03PM +0200, Greg Kroah-Hartman wrote:
> 4.14-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Juergen Gross <jgross@suse.com>
> 
> commit f7c90c2aa4004808dff777ba6ae2c7294dd06851 upstream.
> 
> In some cases 32-bit PAE PV guests still write PTEs directly instead of
> using hypercalls. This is especially bad when clearing a PTE as this is
> done via 32-bit writes which will produce intermediate L1TF attackable
> PTEs.
> 
> Change the code to use hypercalls instead.
> 

Good that we got this in. Should we also take this one:
b2d7a075a1cc ("x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear")

Which is under the line of the same issue?

> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ---
>  arch/x86/xen/mmu_pv.c |    7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -425,14 +425,13 @@ static void xen_set_pud(pud_t *ptr, pud_
>  static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
>  {
>  	trace_xen_mmu_set_pte_atomic(ptep, pte);
> -	set_64bit((u64 *)ptep, native_pte_val(pte));
> +	__xen_set_pte(ptep, pte);
>  }
>  
>  static void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
>  {
>  	trace_xen_mmu_pte_clear(mm, addr, ptep);
> -	if (!xen_batched_set_pte(ptep, native_make_pte(0)))
> -		native_pte_clear(mm, addr, ptep);
> +	__xen_set_pte(ptep, native_make_pte(0));
>  }
>  
>  static void xen_pmd_clear(pmd_t *pmdp)
> @@ -1543,7 +1542,7 @@ static void __init xen_set_pte_init(pte_
>  		pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
>  			       pte_val_ma(pte));
>  #endif
> -	native_set_pte(ptep, pte);
> +	__xen_set_pte(ptep, pte);
>  }
>  
>  /* Early in boot, while setting up the initial pagetable, assume
> 
> 
> 

-- 
All the best,
Eduardo Valentin