[PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations

[Steve Capper]

On 13/10/2020 17:57, Ard Biesheuvel wrote:
> On Tue, 13 Oct 2020 at 18:51, Steve Capper <Steve.Capper at arm.com> wrote:
>>
>> Hi Ard,
>>
>> One comment below...
>>
>> On 08/10/2020 16:36, Ard Biesheuvel wrote:
>>> For historical reasons, the arm64 kernel VA space is configured as two
>>> equally sized halves, i.e., on a 48-bit VA build, the VA space is split
>>> into a 47-bit vmalloc region and a 47-bit linear region.
>>>
>>> When support for 52-bit virtual addressing was added, this equal split
>>> was kept, resulting in a substantial waste of virtual address space in
>>> the linear region:
>>>
>>>                              48-bit VA                     52-bit VA
>>>     0xffff_ffff_ffff_ffff +-------------+               +-------------+
>>>                           |   vmalloc   |               |   vmalloc   |
>>>     0xffff_8000_0000_0000 +-------------+ _PAGE_END(48) +-------------+
>>>                           |   linear    |               :             :
>>>     0xffff_0000_0000_0000 +-------------+               :             :
>>>                           :             :               :             :
>>>                           :             :               :             :
>>>                           :             :               :             :
>>>                           :             :               :  currently  :
>>>                           :  unusable   :               :             :
>>>                           :             :               :   unused    :
>>>                           :     by      :               :             :
>>>                           :             :               :             :
>>>                           :  hardware   :               :             :
>>>                           :             :               :             :
>>>     0xfff8_0000_0000_0000 :             : _PAGE_END(52) +-------------+
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :  unusable   :               |             |
>>>                           :             :               |   linear    |
>>>                           :     by      :               |             |
>>>                           :             :               |   region    |
>>>                           :  hardware   :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>                           :             :               |             |
>>>     0xfff0_0000_0000_0000 +-------------+  PAGE_OFFSET  +-------------+
>>>
>>> As illustrated above, the 52-bit VA kernel uses 47 bits for the vmalloc
>>> space (as before), to ensure that a single 64k granule kernel image can
>>> support any 64k granule capable system, regardless of whether it supports
>>> the 52-bit virtual addressing extension. However, due to the fact that
>>> the VA space is still split in equal halves, the linear region is only
>>> 2^51 bytes in size, wasting almost half of the 52-bit VA space.
>>>
>>> Let's fix this, by abandoning the equal split, and simply assigning all
>>> VA space outside of the vmalloc region to the linear region.
>>>
>>> The KASAN shadow region is reconfigured so that it ends at the start of
>>> the vmalloc region, and grows downwards. That way, the arrangement of
>>> the vmalloc space (which contains kernel mappings, modules, BPF region,
>>> the vmemmap array etc) is identical between non-KASAN and KASAN builds,
>>> which aids debugging.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
>>> ---
>>>    Documentation/arm64/kasan-offsets.sh |  3 +--
>>>    Documentation/arm64/memory.rst       | 19 +++++++++----------
>>>    arch/arm64/Kconfig                   | 20 ++++++++++----------
>>>    arch/arm64/include/asm/memory.h      | 12 +++++-------
>>>    arch/arm64/mm/init.c                 |  2 +-
>>>    5 files changed, 26 insertions(+), 30 deletions(-)
>>>
>>
>> [...]
>>
>>> diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
>>> index cf03b3290800..ee51eb66a578 100644
>>> --- a/Documentation/arm64/memory.rst
>>> +++ b/Documentation/arm64/memory.rst
>>> @@ -32,10 +32,10 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
>>>      -----------------------------------------------------------------------
>>>      0000000000000000  0000ffffffffffff         256TB          user
>>>      ffff000000000000  ffff7fffffffffff         128TB          kernel logical memory map
>>> -  ffff800000000000   ffff9fffffffffff          32TB          kasan shadow region
>>> -  ffffa00000000000   ffffa00007ffffff         128MB          bpf jit region
>>> -  ffffa00008000000   ffffa0000fffffff         128MB          modules
>>> -  ffffa00010000000   fffffdffbffeffff         ~93TB          vmalloc
>>> +[ ffff600000000000   ffff7fffffffffff ]        32TB          [ kasan shadow region ]
>>
>> We have the KASAN shadow region intersecting with the kernel logical
>> memory map now. Could this present a problem if both the KASAN and
>> phys_to_virt paths land on the same VA? Or is that not possible? (Also
>> what about smaller VA sizes?)
>>
>> If it is a problem, could carving out the appropriate memblocks (and
>> warning the user) be a way forward?
>>
> 
> Hi Steve,
> 
> This is currently taken into account in arm64_memblock_init():
> 
> const s64 linear_region_size = PAGE_END - _PAGE_OFFSET(vabits_actual);
> 
> When CONFIG_KASAN=y, PAGE_END is #defined as
> 
> (KASAN_SHADOW_END - (1UL << (vabits_actual - KASAN_SHADOW_SCALE_SHIFT)))
> 
> and so the linear region ends where the KASAN shadow region starts. So
> even if the static definitions overlap, the shared region will not be
> used for mapping memory if it is needed for allocating shadow pages.
> 

Ahhh, yes, thanks that will prevent the intersection from occurring.

This looks good to me, feel free to add:
Reviewed-by: Steve Capper <steve.capper at arm.com>

Cheers,
--
Steve