From: Ard Biesheuvel <ardb+git@google.com>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, will@kernel.org,
catalin.marinas@arm.com, mark.rutland@arm.com,
Ard Biesheuvel <ardb@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Liz Prucka <lizprucka@google.com>,
Seth Jenkins <sethjenkins@google.com>,
Kees Cook <kees@kernel.org>, Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-hardening@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org
Subject: [PATCH v6 00/15] arm64: Unmap linear alias of kernel data/bss
Date: Tue, 26 May 2026 19:58:47 +0200 [thread overview]
Message-ID: <20260526175846.2694125-17-ardb+git@google.com> (raw)
From: Ard Biesheuvel <ardb@kernel.org>
One of the reasons the lack of randomization of the linear map on arm64
is considered problematic is the fact that bootloaders adhering to the
original arm64 boot protocol (i.e., a substantial fraction of all
Android phones) may place the kernel at the base of DRAM, and therefore
at the base of the non-randomized linear map. This puts a writable alias
of the kernel's data and bss regions at a predictable location, removing
the need for an attacker to guess where KASLR mapped the kernel.
Let's unmap this linear, writable alias entirely, so that knowing the
location of the linear alias does not give write access to the kernel's
data and bss regions.
Changes since v5:
- Reorder series in ascending order of impact, so that the first few can
be merged earlier if desired. This also makes the patch that remaps
the data/bss linear alias as tagged redundant, which is therefore
dropped.
- Add patch #3 to address an existing issue spotted by Sashiko
- Fix thinko in contiguous region check (#5), where the whole region
needs to be considered and not only the first entry (dropped Rb as
well) - this addresses the kfence issue Sashiko reported on v5 [0]
- Update commit log on #6 to clarify that changing permission bits on
PTE_CONT entries is safe as long as PTE_CONT itself does not change
- Likewise, drop hunk that adds the PTE_CONT bit to the 'permitted' mask
in pgattr_change_is_safe(), as changing it is not safe. (#8)
- Move kasan's additional page table to pgdir BSS as well
- Use (NOLOAD) on the .pgdir.bss section so it does not get emitted into
vmlinux
- Add powerpc and SuperH patches to deal with empty_zero_page[] being
made const
Changes since v4:
- Update the correct [early] mapping in patch #1
- Make empty_zero_page[] const instead of __ro_after_init
- Drop patches that remap the fixmap page tables r/o for now
- Don't force page mappings for the data/bss linear alias, as it is no
longer needed for set_memory_valid()
- Add acks
Changes since v3:
- Drop bogus patch adding hierarchical PXN to the fixmap mapping, which
breaks the KPTI trampoline (thanks to Sashiko)
- Add generic patch to move the empty_zero_page to __ro_after_init, as
it now lives in generic code.
- Add patches to remap the linear aliases of the fixmap page tables
read-only too - these live at an a priori known offset in the linear
map if physical KASLR was omitted, and control a priori known
addresses in the virtual kernel space.
- Rebase onto v7.1-rc1
Changes since v2:
- Keep bm_pte[] in the region that is remapped r/o or unmapped, as it is
only manipulated via its kernel alias
- Drop check that prohibits any manipulation of descriptors with the
CONT bit set
- Add Ryan's ack to a couple of patches
- Rebase onto v7.0-rc4
Changes since v1:
- Put zero page patch at the start of the series
- Tweak __map_memblock() API to respect existing table and contiguous
mappings, so that the logic to map the kernel alias can be simplified
- Stop abusing the MEMBLOCK_NOMAP flag to initially omit the kernel
linear alias from the linear map
- Some additional cleanup patches
- Use proper API [set_memory_valid()] to (un)map the linear alias of
data/bss.
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc; Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Liz Prucka <lizprucka@google.com>
Cc: Seth Jenkins <sethjenkins@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: linux-mm@kvack.org
Cc: linux-hardening@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
[0] https://sashiko.dev/#/patchset/20260519151616.2557018-15-ardb%2Bgit%40google.com
Ard Biesheuvel (15):
arm64: mm: Remove bogus stop condition from map_mem() loop
arm64: mm: Drop redundant pgd_t* argument from map_mem()
arm64: mm: Check for pud_/pmd_set_huge() failures on kernel mappings
arm64: mm: Preserve existing table mappings when mapping DRAM
arm64: mm: Preserve non-contiguous descriptors when mapping DRAM
arm64: mm: Permit contiguous descriptors to be manipulated
arm64: kfence: Avoid NOMAP tricks when mapping the early pool
arm64: mm: Permit contiguous attribute for preliminary mappings
arm64: Move fixmap and kasan page tables to end of kernel image
arm64: mm: Don't abuse memblock NOMAP to check for overlaps
arm64: mm: Map the kernel data/bss read-only in the linear map
powerpc/code-patching: Avoid r/w mapping of the zero page
sh: cast away constness from the zero page when flushing it from the
cache
mm: Make empty_zero_page[] const
arm64: mm: Unmap kernel data/bss entirely from the linear map
arch/arm64/include/asm/mmu.h | 2 +
arch/arm64/include/asm/pgtable.h | 4 +
arch/arm64/kernel/vmlinux.lds.S | 8 +-
arch/arm64/mm/fixmap.c | 6 +-
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 153 ++++++++++++--------
arch/powerpc/lib/code-patching.c | 52 +------
arch/sh/mm/init.c | 2 +-
include/linux/pgtable.h | 2 +-
mm/mm_init.c | 2 +-
10 files changed, 111 insertions(+), 122 deletions(-)
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.54.0.794.g4f17f83d09-goog
next reply other threads:[~2026-05-26 17:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 17:58 Ard Biesheuvel [this message]
2026-05-26 17:58 ` [PATCH v6 01/15] arm64: mm: Remove bogus stop condition from map_mem() loop Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 02/15] arm64: mm: Drop redundant pgd_t* argument from map_mem() Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 03/15] arm64: mm: Check for pud_/pmd_set_huge() failures on kernel mappings Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 04/15] arm64: mm: Preserve existing table mappings when mapping DRAM Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 05/15] arm64: mm: Preserve non-contiguous descriptors " Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 06/15] arm64: mm: Permit contiguous descriptors to be manipulated Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 07/15] arm64: kfence: Avoid NOMAP tricks when mapping the early pool Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 08/15] arm64: mm: Permit contiguous attribute for preliminary mappings Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 09/15] arm64: Move fixmap and kasan page tables to end of kernel image Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 10/15] arm64: mm: Don't abuse memblock NOMAP to check for overlaps Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 11/15] arm64: mm: Map the kernel data/bss read-only in the linear map Ard Biesheuvel
2026-05-26 17:58 ` [PATCH v6 12/15] powerpc/code-patching: Avoid r/w mapping of the zero page Ard Biesheuvel
2026-05-26 17:59 ` [PATCH v6 13/15] sh: cast away constness from the zero page when flushing it from the cache Ard Biesheuvel
2026-05-26 17:59 ` [PATCH v6 14/15] mm: Make empty_zero_page[] const Ard Biesheuvel
2026-05-26 17:59 ` [PATCH v6 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260526175846.2694125-17-ardb+git@google.com \
--to=ardb+git@google.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lizprucka@google.com \
--cc=mark.rutland@arm.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sethjenkins@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox