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

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Tue, 19 Feb 2019 at 14:01, Will Deacon <will.deacon@arm.com> wrote:
>
> On Tue, Feb 19, 2019 at 01:51:51PM +0100, Ard Biesheuvel wrote:
> > On Tue, 19 Feb 2019 at 13:48, Will Deacon <will.deacon@arm.com> wrote:
> > >
> > > On Tue, Feb 19, 2019 at 01:13:32PM +0100, Ard Biesheuvel wrote:
> > > > On Mon, 18 Feb 2019 at 18:05, Steve Capper <steve.capper@arm.com> wrote:
> > > > >
> > > > > This patch series adds support for 52-bit kernel VAs using some of the
> > > > > machinery already introduced by the 52-bit userspace VA code in 5.0.
> > > > >
> > > > > As 52-bit virtual address support is an optional hardware feature,
> > > > > software support for 52-bit kernel VAs needs to be deduced at early boot
> > > > > time. If HW support is not available, the kernel falls back to 48-bit.
> > > > >
> > > > > A significant proportion of this series focuses on "de-constifying"
> > > > > VA_BITS related constants.
> > > > >
> > > > > In order to allow for a KASAN shadow that changes size at boot time, one
> > > > > must fix the KASAN_SHADOW_END for both 48 & 52-bit VAs and "grow" the
> > > > > start address. Also, it is highly desirable to maintain the same
> > > > > function addresses in the kernel .text between VA sizes. Both of these
> > > > > requirements necessitate us to flip the kernel address space halves s.t.
> > > > > the direct linear map occupies the lower addresses.
> > > > >
> > > > > One obvious omission is 52-bit kernel VA + 48-bit userspace VA which I
> > > > > can add with some more #ifdef'ery if needed.
> > > > >
> > > >
> > > > Hi Steve,
> > > >
> > > > Apologies if I am bringing up things that have been addressed
> > > > internally already. We discussed the 52-bit kernel VA work at
> > > > plumber's at some point, and IIUC, KASAN is the complicating factor
> > > > when it comes to having compile time constants for VA_BITS_MIN,
> > > > VA_BITS_MAX and PAGE_OFFSET, right?
> > > >
> > > > To clarify what I mean, please refer to the diagram below, which
> > > > describes a hybrid 48/52 kernel VA arrangement that does not rely on
> > > > runtime variable quantities. (VA_BITS_MIN == 48, VA_BITS_MAX == 52)
> > > >
> > > > +------------------- (~0) -------------------------+
> > > > |                                                |
> > > > |            PCI IO / fixmap spaces              |
> > > > |                                                |
> > > > +------------------------------------------------+
> > > > |                                                |
> > > > |             kernel/vmalloc space               |
> > > > |                                                |
> > > > +------------------------------------------------+
> > > > |                                                |
> > > > |                module space                    |
> > > > |                                                |
> > > > +------------------------------------------------+
> > > > |                                                |
> > > > |                BPF space                       |
> > > > |                                                |
> > > > +------------------------------------------------+
> > > > |                                                |
> > > > |                                                |
> > > > |   vmemmap space (size based on VA_BITS_MAX)    |
> > > > |                                                |
> > > > |                                                |
> > > > +-- linear/vmalloc split based on VA_BITS_MIN -- +
> > > > |                                                |
> > > > |    linear mapping (48 bit addressable region)  |
> > > > |                                                |
> > > > +------------------------------------------------+
> > > > |                                                |
> > > > |    linear mapping (52 bit addressable region)  |
> > > > |                                                |
> > > > +------ PAGE_OFFSET based on VA_BITS_MAX --------+
> > > >
> > > > Since KASAN is what is preventing this, would it be acceptable for
> > > > KASAN to only be supported when you use a true 48 bit or a true 52 bit
> > > > configuration, and disable it for the 48/52 hybrid configuration?
> > > >
> > > > Just thinking out loud (and in ASCII art :-))
> > >
> > > TBH, if we end up having support for 52-bit kernel VA, I'd be inclined to
> > > drop the 48/52 configuration altogether. But Catalin's on holiday at the
> > > moment, and may have a different opinion ;)
> > >
> >
> > But that implies that you cannot have an image that supports 52-bit
> > kernel VAs but can still boot on hardware that does not implement
> > support for it. If that is acceptable, then none of this hoop jumping
> > that Steve is doing in these patches is necessary to begin with,
> > right?
>
> Sorry, I misunderstood what you meant by a "48/52 hybrid configuration". I
> thought you were referring to the configuration where userspace is 52-bit
> and the kernel is 48-bit, which is something I think we can drop if we gain
> support for 52-bit kernel.
>
> Now that I understand what you mean, I think disabling KASAN would be fine
> as long as it's a runtime thing and the kernel continues to work in every
> other respect.
>

No, it would be a limitation of the 52-bit config which also supports
48-bit-VA-only-h/w that the address space is laid out in such a way
that there is simply no room for the KASAN shadow region, since it
would have to live in the 48-bit addressable area, but be big enough
to cover 52 bits of VA, which is impossible.

For the vmemmap space, we could live with sizing it statically to
cover a 52-bit VA linear region, but the KASAN shadow region is simply
too big.

So if KASAN support in that configuration is a requirement, then I
agree with Steve's approach, but it does imply that quite a number of
formerly compile-time constants now get turned into runtime variables.

Steve, do you have any idea what the impact of that is?

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