On Wed, 29 Apr 2026, at 15:54, Kevin Brodsky wrote:
> On 27/04/2026 17:34, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <[email protected]>
>>
>> On systems where the bootloader adheres to the original arm64 boot
>> protocol, the placement of the kernel in the physical address space is
>> highly predictable, and this makes the placement of its linear alias in
>> the kernel virtual address space equally predictable, given the lack of
>> randomization of the linear map.
>>
>> The linear aliases of the kernel text and rodata regions are already
>> mapped read-only, but the kernel data and bss are mapped read-write in
>> this region. This is not needed, so map them read-only as well.
>>
>> Note that the statically allocated kernel page tables do need to be
>> modifiable via the linear map, so leave these mapped read-write.
>>
>> Signed-off-by: Ard Biesheuvel <[email protected]>
>> ---
>> arch/arm64/include/asm/sections.h | 1 +
>> arch/arm64/mm/mmu.c | 16 ++++++++++++++--
>> 2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/sections.h
>> b/arch/arm64/include/asm/sections.h
>> index 51b0d594239e..32ec21af0823 100644
>> --- a/arch/arm64/include/asm/sections.h
>> +++ b/arch/arm64/include/asm/sections.h
>> @@ -23,6 +23,7 @@ extern char __irqentry_text_start[], __irqentry_text_end[];
>> extern char __mmuoff_data_start[], __mmuoff_data_end[];
>> extern char __entry_tramp_text_start[], __entry_tramp_text_end[];
>> extern char __relocate_new_kernel_start[], __relocate_new_kernel_end[];
>> +extern char __fixmap_pgdir_start[];
>>
>> static inline size_t entry_tramp_text_size(void)
>> {
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 1a4b4337d29a..9361b7efb848 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1122,7 +1122,9 @@ static void __init map_mem(void)
>> {
>> static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN);
>> phys_addr_t kernel_start = __pa_symbol(_text);
>> - phys_addr_t kernel_end = __pa_symbol(__init_begin);
>> + phys_addr_t init_begin = __pa_symbol(__init_begin);
>> + phys_addr_t init_end = __pa_symbol(__init_end);
>> + phys_addr_t kernel_end = __pa_symbol(__fixmap_pgdir_start);
>
> Using fixmap_pgdir as an anchor seems a bit arbitrary... Couldn't we use
> __bss_end instead?
>
> It could also be helpful to add comments in vmlinux.lds.S clarifying
> which sections are RO/RW in the linear map, it's getting pretty
> difficult to follow.
>
Ack.
>> phys_addr_t start, end;
>> int flags = NO_EXEC_MAPPINGS;
>> u64 i;
>> @@ -1155,7 +1157,11 @@ static void __init map_mem(void)
>> * of the region accessible to subsystems such as hibernate,
>> * but protects it from inadvertent modification or execution.
>> */
>> - __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
>> + __map_memblock(kernel_start, init_begin, pgprot_tagged(PAGE_KERNEL),
>> + flags);
>> +
>> + /* Map the kernel data/bss so it can be remapped later */
>> + __map_memblock(init_end, kernel_end, pgprot_tagged(PAGE_KERNEL),
>
> Maybe I'm missing something obvious, but considering patch 3/4 couldn't
> we directly map the range RO here?
>
After 3/4, __map_memblock() will no longer combine new mappings with existing
ones into block mappings or contiguous ranges. However, it will still set the
requested type and permission attributes on the entire range, and so the second
invocation is needed to restore the read-only bit.
IOW, we could also map it read-only twice, the result would be the same, but the
second call is still needed.
