On Tue, 19 Feb 2019 at 14:01, Will Deacon [off-list ref] wrote:

On Tue, Feb 19, 2019 at 01:51:51PM +0100, Ard Biesheuvel wrote:

quoted

On Tue, 19 Feb 2019 at 13:48, Will Deacon [off-list ref] wrote:

quoted

On Tue, Feb 19, 2019 at 01:13:32PM +0100, Ard Biesheuvel wrote:

quoted

On Mon, 18 Feb 2019 at 18:05, Steve Capper [off-list ref] wrote:

quoted

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