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] [day] [month] [year] [list]

Message-ID: <DB7PR04MB4490EAD2E829E17CCE81C5F188660@DB7PR04MB4490.eurprd04.prod.outlook.com>
Date:   Wed, 13 Feb 2019 11:54:55 +0000
From:   Peng Fan <peng.fan@....com>
To:     Mark Rutland <mark.rutland@....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

Hi Mark,

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@....com]
> Sent: 2019年2月13日 19:31
> To: Peng Fan <peng.fan@....com>
> Cc: catalin.marinas@....com; will.deacon@....com;
> ard.biesheuvel@...aro.org; yaojun8558363@...il.com;
> cpandya@...eaurora.org; robin.murphy@....com;
> linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org;
> 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.

Thanks, I understand wrong.

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

I though the barrier in __pgd_populate could be enough, but this is not
enough, we still need barrier before write pgd/pud/pmd/pte entries.

So drop this patch.

Thanks,
Peng.

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