arch/arm64/include/asm/fixmap.h | 4 ++ arch/arm64/include/asm/linkage.h | 1 + arch/arm64/include/asm/pgtable.h | 55 ++++++++------------ arch/arm64/kernel/vmlinux.lds.S | 6 +++ arch/arm64/mm/fixmap.c | 12 +++-- arch/arm64/mm/mmu.c | 48 +++++++++++++---- 6 files changed, 78 insertions(+), 48 deletions(-)
From: Ard Biesheuvel <ardb@kernel.org> This v2 now covers intermediate level page tables as well as the PTE level page table for the fixmap. The latter is a special case, as it a) is only accessed via the kernel image's mapping, and never via the linear map (except for ptdump etc) b) must be accessible via a read-write mapping, as all manipulation of read-only page table descriptors relies on the fixmap itself and so it is treated separately. The intermediate page tables may be shared with other mappings in the upper kernel/vmalloc region, so they must be updatable using the ordinary APIs. Build tested and boot tested on a Lenovo Yoga C630 using 16k pages. v1: https://lore.kernel.org/all/20260805104042.1107678-2-ardb+git@google.com/ 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: Jann Horn <jannh@google.com> Cc: linux-hardening@vger.kernel.org Ard Biesheuvel (4): arm64: mm: Map fixmap PTE tables r/o in the linear map arm64: mm: Use fault handler to permit swapper_pg_dir updates arm64: mm: Create r/o page table region that permits updates arm64: mm: Move fixmap intermediate page tables into .rodata arch/arm64/include/asm/fixmap.h | 4 ++ arch/arm64/include/asm/linkage.h | 1 + arch/arm64/include/asm/pgtable.h | 55 ++++++++------------ arch/arm64/kernel/vmlinux.lds.S | 6 +++ arch/arm64/mm/fixmap.c | 12 +++-- arch/arm64/mm/mmu.c | 48 +++++++++++++---- 6 files changed, 78 insertions(+), 48 deletions(-) -- 2.55.0.887.g758fc8c411-goog
On 27/08/2026 18:44, Ard Biesheuvel wrote: > From: Ard Biesheuvel <ardb@kernel.org> > > This v2 now covers intermediate level page tables as well as the PTE > level page table for the fixmap. The latter is a special case, as it > > a) is only accessed via the kernel image's mapping, and never via the > linear map (except for ptdump etc) > > b) must be accessible via a read-write mapping, as all manipulation of > read-only page table descriptors relies on the fixmap itself > > and so it is treated separately. The intermediate page tables may be > shared with other mappings in the upper kernel/vmalloc region, so they > must be updatable using the ordinary APIs. > > Build tested and boot tested on a Lenovo Yoga C630 using 16k pages. > > v1: https://lore.kernel.org/all/20260805104042.1107678-2-ardb+git@google.com/ > > 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: Jann Horn <jannh@google.com> > Cc: linux-hardening@vger.kernel.org Looks like the Cc's didn't propagate to the actual patches, fortunately my lei filters did catch this series ;) Either way I quite like this series, it's an elegant approach and it should increase security without overhead, what's not to like! I also considered it from the perspective of kpkeys protection [1] and I think they should work together fine. The kpkeys series still allows page table setters to write to all page tables, so if we get a fault there it must be because the target is read only, and not because of a pkey fault. - Kevin [1] https://lore.kernel.org/all/20260818-kpkeys-v9-0-743ad31b2c8f@arm.com/
On Tue, 1 Sep 2026, at 11:21, Kevin Brodsky wrote: > On 27/08/2026 18:44, Ard Biesheuvel wrote: >> From: Ard Biesheuvel <ardb@kernel.org> >> >> This v2 now covers intermediate level page tables as well as the PTE >> level page table for the fixmap. The latter is a special case, as it >> >> a) is only accessed via the kernel image's mapping, and never via the >> linear map (except for ptdump etc) >> >> b) must be accessible via a read-write mapping, as all manipulation of >> read-only page table descriptors relies on the fixmap itself >> >> and so it is treated separately. The intermediate page tables may be >> shared with other mappings in the upper kernel/vmalloc region, so they >> must be updatable using the ordinary APIs. >> >> Build tested and boot tested on a Lenovo Yoga C630 using 16k pages. >> >> v1: https://lore.kernel.org/all/20260805104042.1107678-2-ardb+git@google.com/ >> >> 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: Jann Horn <jannh@google.com> >> Cc: linux-hardening@vger.kernel.org > > Looks like the Cc's didn't propagate to the actual patches, fortunately > my lei filters did catch this series ;) > Ugh I must have forgotten to put --cc-cover > Either way I quite like this series, it's an elegant approach and it > should increase security without overhead, what's not to like! > > I also considered it from the perspective of kpkeys protection [1] and I > think they should work together fine. The kpkeys series still allows > page table setters to write to all page tables, so if we get a fault > there it must be because the target is read only, and not because of a > pkey fault. > Excellent, thanks for confirming.
© 2016 - 2026 Red Hat, Inc.