linux-kernel - Re: [PATCH 3/3] arm64: mmu: pgd_pgtable

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190213113050.GC22119@lakrids.cambridge.arm.com>
Date:   Wed, 13 Feb 2019 11:30:51 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Peng Fan <peng.fan@....com>
Cc:     "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "yaojun8558363@...il.com" <yaojun8558363@...il.com>,
        "cpandya@...eaurora.org" <cpandya@...eaurora.org>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "van.freenix@...il.com" <van.freenix@...il.com>
Subject: Re: [PATCH 3/3] arm64: mmu: pgd_pgtable_alloc: drop barrier

On Wed, Feb 13, 2019 at 09:37:38AM +0000, Peng Fan wrote:
> The barriers are added for empty_zero_page, however the
> empty zero page has been moved to bss area by
> commit 5227cfa71f9e ("arm64: mm: place empty_zero_page in bss"),
> and it alreay added "dsb     ishst" in head.S to make sure
> the empty zero page visible to PTW.

The "zeroed page" the comment refers to is not empty_zero_page.

The page
the comment refers to is an arbitrary page returned by
__get_free_page(), which has been filled with zeroed at some point
thanks to PGALLOC_GFP containing __GFP_ZERO.

> pgd_pgtable_alloc is only called by __create_pgd_mapping, and
> there are implicit barriers in __create_pgd_mapping, so we
> could remove the barrier pgd_pgtable_alloc

I don't think this is true.

Consider:

  create_pgd_mapping()
  -> __create_pgd_mapping()
     -> alloc_init_pud()
        -> pgtable_alloc() // pgd_pgtable_alloc()
	-> __pgd_populate()

... where AFAICT there is no barrier between pgtable_alloc() and
__pgd_populate().

Where is the barrier between the page zeroing and the update of the pgd
entry?

Thanks,
Mark.

> 
> Signed-off-by: Peng Fan <peng.fan@....com>
> ---
> 
> Note: this patch tested on qemu-system-aarch64, not real hardware.
> 
>  arch/arm64/mm/mmu.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index f61fa7c8fd2e..04e3d4d070ce 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -371,8 +371,6 @@ static phys_addr_t pgd_pgtable_alloc(void)
>  	if (!ptr || !pgtable_page_ctor(virt_to_page(ptr)))
>  		BUG();
>  
> -	/* Ensure the zeroed page is visible to the page table walker */
> -	dsb(ishst);
>  	return __pa(ptr);
>  }
>  
> -- 
> 2.16.4
>