Re: [RFC PATCH] arm64: mm: Map fixmap PTE tables r/o in the linear map

["Ard Biesheuvel" <ardb@kernel.org>]

On Fri, 21 Aug 2026, at 15:20, Kevin Brodsky wrote:
> On 05/08/2026 12:40, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>>
>> Without physical KASLR, the fixmap page tables will appear at an a
>> priori known offset in the physical address space, and due to the lack
>> of randomization, the linear map carries a writeable alias of the fixmap
>> PTE pages, which appears at an offset in the kernel VA space that is
>> also predictable.
>>
>> Given that the placement of the fixmap area is never randomized either,
>> a single store to this linear alias region is sufficient to map any
>> physical page with any permissions at a known offset in the kernel VA
>> space, including on top of the PTI trampoline.
>>
>> Avoid this, by remapping the fixmap PTE pages read-only in the linear
>> map.
>
> Sounds good, logical next step after unmapping the rest of data/BSS from
> the linear map :)
>

Indeed :-)

>> This is possible because all updates to bm_pte[] occur via the
>> mapping of the kernel image in the vmap area. A read-only mapping is
>> still needed for things like ptdump that walk the page tables.
>>
>> 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
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>>  arch/arm64/include/asm/set_memory.h |  2 ++
>>  arch/arm64/mm/fixmap.c              |  7 +++++++
>>  arch/arm64/mm/pageattr.c            | 10 ++++++++++
>>  3 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/set_memory.h b/arch/arm64/include/asm/set_memory.h
>> index 90f61b17275e..a685fb534c3e 100644
>> --- a/arch/arm64/include/asm/set_memory.h
>> +++ b/arch/arm64/include/asm/set_memory.h
>> @@ -11,6 +11,8 @@ bool can_set_direct_map(void);
>>  
>>  int set_memory_valid(unsigned long addr, int numpages, int enable);
>>  
>> +int set_direct_map_ro(unsigned long addr, int numpages);
>> +
>>  int set_direct_map_invalid_noflush(struct page *page);
>>  int set_direct_map_default_noflush(struct page *page);
>>  int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
>> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
>> index f66a0016dd02..fcb571dffe82 100644
>> --- a/arch/arm64/mm/fixmap.c
>> +++ b/arch/arm64/mm/fixmap.c
>> @@ -14,6 +14,7 @@
>>  #include <asm/fixmap.h>
>>  #include <asm/kernel-pgtable.h>
>>  #include <asm/pgalloc.h>
>> +#include <asm/set_memory.h>
>>  #include <asm/tlbflush.h>
>>  
>>  /* ensure that the fixmap region does not grow down into the PCI I/O region */
>> @@ -173,3 +174,9 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
>>  
>>  	return dt_virt;
>>  }
>> +
>> +static int __init fixmap_remap_ro(void)
>> +{
>> +	return set_direct_map_ro((unsigned long)lm_alias(&bm_pte), NR_BM_PTE_TABLES);
>
> Should we not also remap bm_pmd and bm_pud?
>
> For that matter, do we need RW access via the linear map for any page
> annotated with __bss_pgtbl? I suppose that might be the case for
> kasan_early_shadow_* but I don't know enough about KASAN to tell for sure.
>

bm_pte[] is special because it is only ever written via the kernel mapping,
and never via the linear map. This is why it is being singled out in this
patch.

Whether or not bm_pmd[] can be treated as a special case depends on the page
size: with 4k pages, the whole array covers a virtual region of 1G, which is
currently guaranteed to be shared only with the PCI I/O space (but we could
move that out). With 16k pages, it covers 64G, and so it is shared with the
vmemmap and other virtual mappings in the vmalloc region, and so the current
kernel mapping code expects to be able to write those entries.

What we might do is generalize the logic that uses the fixmap to modify
pgd level entries in swapper_pg_dir, and use it for all modifications
at PMD level or higher if those tables are in .rodata

But this is a bit more complicated than this change, so I decided to
present this as a separate change.

>> +}
>> +late_initcall(fixmap_remap_ro);
>
> Is mark_rodata_ro() definitely too early to remap these pages RO?
>

No, we might just call this from there, afaict.