linux-kernel - Re: [PATCH v3 09/60] arm64: mm: Reclaim unused vmemmap region for vmalloc use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Mar 2023 16:42:36 +0000
From:   Ryan Roberts <ryan.roberts@....com>
To:     Ard Biesheuvel <ardb@...nel.org>, linux-kernel@...r.kernel.org
Cc:     linux-arm-kernel@...ts.infradead.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v3 09/60] arm64: mm: Reclaim unused vmemmap region for
 vmalloc use

On 07/03/2023 14:04, Ard Biesheuvel wrote:
> The vmemmap array is statically sized based on the maximum supported
> size of the virtual address space, but it is located inside the upper VA
> region, which is statically sized based on the *minimum* supported size
> of the VA space. This doesn't matter much when using 64k pages, which is
> the only configuration that currently supports 52-bit virtual
> addressing.

As I understand it, the vmemmap section only holds struct pages, and the number
of struct pages in the system is surely a function of PA size, not VA size? So
why is the region sized based on VA size?

> 
> However, upcoming LPA2 support will change this picture somewhat, as in
> that case, the vmemmap array will take up more than 25% of the upper VA
> region when using 4k pages. Given that most of this space is never used
> when running on a system that does not support 52-bit virtual
> addressing, let's reclaim the unused vmemmap area in that case.
> 
> Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> ---
>  arch/arm64/include/asm/pgtable.h | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 3eff06c5d0eb73c7..2259898e8c3d990a 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -18,11 +18,15 @@
>   * VMALLOC range.
>   *
>   * VMALLOC_START: beginning of the kernel vmalloc space
> - * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space
> - *	and fixed mappings
> + * VMALLOC_END: extends to the available space below vmemmap
>   */
>  #define VMALLOC_START		(MODULES_END)
> +#if VA_BITS == VA_BITS_MIN
>  #define VMALLOC_END		(VMEMMAP_START - SZ_8M)
> +#else
> +#define VMEMMAP_UNUSED_NPAGES	((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT)
> +#define VMALLOC_END		(VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M)
> +#endif
>  
>  #define vmemmap			((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
>