linux-kernel - [RFC PATCH 0/8] arm64: Simplify VA space configurations

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-next>] [day] [month] [year] [list]

Message-ID: <20241030101803.2037606-10-ardb+git@google.com>
Date: Wed, 30 Oct 2024 11:18:04 +0100
From: Ard Biesheuvel <ardb+git@...gle.com>
To: linux-arm-kernel@...ts.infradead.org
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, Ryan Roberts <ryan.roberts@....com>, 
	Anshuman Khandual <anshuman.khandual@....com>, Kees Cook <keescook@...omium.org>
Subject: [RFC PATCH 0/8] arm64: Simplify VA space configurations

From: Ard Biesheuvel <ardb@...nel.org>

For historical reasons, we currently support many combinations of page
size and virtual address space size:
- the original arm64 port used only 3 levels of paging (4k/39 bits), and
  the 4 level configuration was only added later
- LVA support on 64k pages could not be disabled at boot, and so it was
  added as a completely separate configuration, even though the number
  of translation levels is the same
- 16k pages gains only 1 bit of VA space when going from 3 to 4 levels
  of translation, and so both are supported
- 16k/36 bits is supported under CONFIG_EXPERT, but 36 bits is a bit on
  the small side for the kernel.

Let's simplify this, by
- removing the configurations that are also the fallbacks on LPA/LPA2
  capable hardware,
- converting 36, 42 and 39 bit configurations into reduced definitions
  of TASK_SIZE, while keeping the larger VA space on the kernel side,
- dropping 16k/48 bits altogether.

The remaining configurations always support up to 52-bit virtual
addressing on the kernel side, and implement the reduced userland VA
space sizes by skipping levels when programming TTBR0_EL1. This is a
quick and dirty hack, but sufficient for the purposes of this RFC.

Cc: Catalin Marinas <catalin.marinas@....com>
Cc: Will Deacon <will@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>
Cc: Ryan Roberts <ryan.roberts@....com>
Cc: Anshuman Khandual <anshuman.khandual@....com>
Cc: Kees Cook <keescook@...omium.org>

Ard Biesheuvel (8):
  arm64/Kconfig: force ARM64_PAN=y when enabling TTBR0 sw PAN
  arm64/Kconfig: fix ARCH_MMAP_RND_BITS_MAX for 52-bit virtual
    addressing
  arm64/Kconfig: eliminate 64k/48-bit VA combination
  arm64/Kconfig: eliminate 4k/48-bit VA combination
  arm64/Kconfig: Drop support for 47-bit virtual addressing
  arm64/Kconfig: Drop support for 48-bit virtual addressing
  arm64/mm: Use reduced VA sizes (36/39/42 bits) only for user space
  arm64/mm: Account for reduced VA sizes in T0SZ and skip the levels

 arch/arm64/Kconfig                     | 89 ++++++++------------
 arch/arm64/include/asm/assembler.h     |  2 +-
 arch/arm64/include/asm/memory.h        |  4 -
 arch/arm64/include/asm/mmu_context.h   |  9 +-
 arch/arm64/include/asm/pgtable-hwdef.h |  2 -
 arch/arm64/include/asm/processor.h     |  6 +-
 arch/arm64/kernel/cpufeature.c         |  2 -
 arch/arm64/kernel/head.S               |  4 -
 arch/arm64/mm/init.c                   |  4 +-
 arch/arm64/mm/pgd.c                    |  9 +-
 arch/arm64/mm/proc.S                   |  2 -
 11 files changed, 52 insertions(+), 81 deletions(-)

-- 
2.47.0.163.g1226f6d8fa-goog