Re: [PATCH 0/9] 52-bit kernel + user VAs

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "crecklin@redhat.com" <crecklin@redhat.com>,
	Steve Capper <Steve.Capper@arm.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Will Deacon <Will.Deacon@arm.com>, nd <nd@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/9] 52-bit kernel + user VAs
Date: Mon, 25 Mar 2019 21:32:52 +0100	[thread overview]
Message-ID: <CAKv+Gu8PB2mKxUy0vxxxCHZ-10f0ruXPd4SAse4V5fVR9mrCdw@mail.gmail.com> (raw)
In-Reply-To: <20190325183828.ztcbclto5lztaajm@mbp>

On Mon, 25 Mar 2019 at 19:38, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Thu, Feb 28, 2019 at 12:22:09PM +0100, Ard Biesheuvel wrote:
> > On Thu, 28 Feb 2019 at 11:36, Steve Capper <Steve.Capper@arm.com> wrote:
> > > The 48/52 bit linear regions above do not overlap and this creates the
> > > following issue.
> >
> > OK, I see what you mean (I think). In my proposal, the linear regions
> > *do* overlap.
> >
> > In my example, the vmemmap region is only sized to cover 51 bits of
> > linear region, but this is not sufficient, since the 52-bit linear
> > region is actually bigger than that.
> >
> > So based on a linear region that goes from
> >
> > FFF0_0000_0000_0000 ... FFFF_8000_0000_0000
> >
> > we would end up with a vmemmap region
> >
> > FFFF_8000_0000_0000 ... FFFF_83E0_0000_0000
> >
> > covering the entire combined linear region.  This is a fair chunk of
> > the vmalloc space for 48-bit configuration, but I don't think that is
> > anything to worry about.
>
> So that's about 42-bit for vmemmap (my calculations were 2^(52-16+6),
> assuming a 64 byte sizeof(page)), so 1/64 of the 48-bit va space. I
> don't think that's a problem.
>
> > > To go from a struct page * to a linear address we do the following:
> > > lva = (page - VMEMMAP_START) * PAGE_SIZE / sizeof(struct page) + PAGE_OFFSET
> >
> > OK, so given the above correction, we can take
> >
> > VMEMMAP_START := FFFF_8000_0000_0000
> > PAGE_OFFSET := FFF0_0000_0000_0000
> >
> > and everything still adds up afaict, and struct pages in the 48-bit VA
> > region are covered from FFFF_83C0_0000_0000 and up.
> >
> > > (Before my series) all the constants are fixed at compile time and thus
> > > translation is very quick. My understanding is that you would like
> > > PAGE_OFFSET to be constant to preserve the optimised nature of this
> > > transform? (if not, please shout :-) )
> >
> > Yes, the main idea is to have compile time constants for PAGE_OFFSET,
> > VA_BITS, etc
>
> If we can have all of the constant, it would be great (we managed from
> the early versions of the patch to have VA_BITS constant).
>
> I have to figure out the KASan story with this (still parsing this
> thread). Can we still get KASan and single-image in the 52-bit VA
> configuration? Or, at least, not have the kernel fall apart if a 52-bit
> image is booted on 48-bit hw with KASan enabled, whether KASan still
> works or not (to get the chance to print some warning)?
>

It should work in both cases, but there will be a part of the linear
region that is used as KASAN shadow on 52-bit hardware, and as a
linear mapping on 48-bit hardware. I'm pretty sure this shouldn't be a
problem, but someone has to double check (and perhaps some boundary
definition macros for KASAN need to be turned into runtime variables)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel