On Fri, 29 May 2026, at 10:29, Kevin Brodsky wrote:
> On 26/05/2026 19:59, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <[email protected]>
>>
>> The linear aliases of the kernel text and rodata are mapped read-only in
>> the linear map as well. Given that the contents of these regions are
>> mostly identical to the version in the loadable image, mapping them
>> read-only and leaving their contents visible is a reasonable hardening
>> measure.
>>
>> Data and bss, however, are now also mapped read-only but the contents of
>> these regions are more likely to contain data that we'd rather not leak.
>> So let's unmap these entirely in the linear map when the kernel is
>> running normally.
>>
>> When going into hibernation or waking up from it, these regions need to
>> be mapped, so map the region initially, and toggle the valid bit so
>> map/unmap the region as needed. (While the hibernation snapshot logic
>> seems able to map inaccessible pages as needed, it currently disregards
>> non-present pages entirely.)
>
> I'm not sure I understand this, is there something wrong with the
> kernel_page_present() check in safe_copy_page()?
>

No. If the hibernate code decides to snapshot a page and it is not mapped,
safe_copy_page() will do the right thing and map it on demand.

The problem is that pages belonging to the kernel image are marked as
PageReserved, and so the hibernation logic will not even consider the
pages for snapshotting if they are not mapped.

>> Signed-off-by: Ard Biesheuvel <[email protected]>
>> ---
>>  arch/arm64/mm/mmu.c | 39 +++++++++++++++++---
>>  1 file changed, 34 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index e7ca53d20b87..cb00e42abbe1 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -24,6 +24,7 @@
>>  #include <linux/mm.h>
>>  #include <linux/vmalloc.h>
>>  #include <linux/set_memory.h>
>> +#include <linux/suspend.h>
>>  #include <linux/kfence.h>
>>  #include <linux/pkeys.h>
>>  #include <linux/mm_inline.h>
>> @@ -1056,6 +1057,29 @@ static void __init __map_memblock(phys_addr_t start, 
>> phys_addr_t end,
>>                               end - start, prot, early_pgtable_alloc, flags);
>>  }
>>  
>> +static void remap_linear_data_alias(bool unmap)
>> +{
>> +    set_memory_valid((unsigned long)lm_alias(__init_end),
>> +                     (unsigned long)(__bss_stop - __init_end) / PAGE_SIZE,
>> +                     !unmap);
>> +}
>> +
>> +static int arm64_hibernate_pm_notify(struct notifier_block *nb,
>> +                                 unsigned long mode, void *unused)
>> +{
>> +    switch (mode) {
>> +    default:
>> +            break;
>> +    case PM_POST_HIBERNATION:
>> +            remap_linear_data_alias(true);
>> +            break;
>> +    case PM_HIBERNATION_PREPARE:
>> +            remap_linear_data_alias(false);
>> +            break;
>> +    }
>> +    return 0;
>> +}
>> +
>>  void __init mark_linear_text_alias_ro(void)
>>  {
>>      /*
>> @@ -1064,6 +1088,16 @@ void __init mark_linear_text_alias_ro(void)
>>      update_mapping_prot(__pa_symbol(_text), (unsigned long)lm_alias(_text),
>>                          (unsigned long)__init_begin - (unsigned long)_text,
>>                          PAGE_KERNEL_RO);
>> +
>> +    remap_linear_data_alias(true);
>
> As suggested on v4, something like mark_linear_data_alias_valid(false)
> would be clearer.
>

Ack.

> Also, is there anything stopping us from doing that directly in map_mem()?
>

Excellent question. I will investigate.


Reply via email to