[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160111173154.GB6105@leverpostej>
Date: Mon, 11 Jan 2016 17:31:54 +0000
From: Mark Rutland <mark.rutland@....com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
kernel-hardening@...ts.openwall.com,
Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
Leif Lindholm <leif.lindholm@...aro.org>,
Kees Cook <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stuart Yoder <stuart.yoder@...escale.com>,
Sharma Bhupesh <bhupesh.sharma@...escale.com>,
Arnd Bergmann <arnd@...db.de>, Marc Zyngier <marc.zyngier@....com>,
Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v3 06/21] arm64: pgtable: implement static
[pte|pmd|pud]_offset variants
On Mon, Jan 11, 2016 at 06:28:51PM +0100, Ard Biesheuvel wrote:
> On 11 January 2016 at 17:24, Mark Rutland <mark.rutland@....com> wrote:
> > On Mon, Jan 11, 2016 at 02:18:59PM +0100, Ard Biesheuvel wrote:
> >> The page table accessors pte_offset(), pud_offset() and pmd_offset()
> >> rely on __va translations, so they can only be used after the linear
> >> mapping has been installed. For the early fixmap and kasan init routines,
> >> whose page tables are allocated statically in the kernel image, these
> >> functions will return bogus values. So implement pmd_offset_kimg() and
> >> pud_offset_kimg(), which can be used instead before any page tables have
> >> been allocated dynamically.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> >
> > This looks good to me. One possible suggsetion below, but either way:
> >
> > Reviewed-by: Mark Rutland <mark.rutland@....com>
> >
> >> ---
> >> arch/arm64/include/asm/pgtable.h | 13 +++++++++++++
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> >> index 6129f6755081..7b4e16068c9f 100644
> >> --- a/arch/arm64/include/asm/pgtable.h
> >> +++ b/arch/arm64/include/asm/pgtable.h
> >> @@ -449,6 +449,9 @@ static inline phys_addr_t pmd_page_paddr(pmd_t pmd)
> >>
> >> #define pmd_page(pmd) pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
> >>
> >> +/* use ONLY for statically allocated translation tables */
> >> +#define pte_offset_kimg(dir,addr) ((pte_t *)__phys_to_kimg(pte_offset_phys((dir), (addr))))
> >> +
> >
> > Given that we're probably only going to use this during one-off setup,
> > maybe it's worth something like:
> >
> > #define IN_KERNEL_IMAGE(p) ({ \
> > unsigned long __p = (unsigned long)p; \
> > KIMAGE_VADDR <= __p && __p < _end; \
> > })
> >
> > #define pte_offset_kimg(dir,addr) ({ \
> > BUG_ON(!IN_KERNEL_IMAGE(dir)); \
> > ((pte_t *)__phys_to_kimg(pte_offset_phys((dir), (addr)))); \
> > })
> >
> > That might be overkill, though, given all it does is turn one runtime
> > failure into another runtime failure.
> >
>
> Yes. I did consider implementing them out of line, with __init
> annotations so you at least get complaints if you refer to them from
> non-init code, but I don't see how we would ever need these anywhere
> beyond fixmap and kasan anyway
Ok. Let's forget about that for now then. :)
Mark.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
