How does swsusp work with randomization features? (was: mm/slab: Initialise random_kmalloc_seed after initcalls)

["Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com>]

On Thu, Feb 13, 2025 at 11:20:22AM +0800, Huacai Chen wrote:
> Hi, Harry,
> 
> On Wed, Feb 12, 2025 at 11:39 PM Harry (Hyeonggon) Yoo
> <42.hyeyoo@gmail.com> wrote:
> > On Wed, Feb 12, 2025 at 11:17 PM Huacai Chen <chenhuacai@loongson.cn> wrote:
> > >
> > > Hibernation assumes the memory layout after resume be the same as that
> > > before sleep, but CONFIG_RANDOM_KMALLOC_CACHES breaks this assumption.
> >
> > Could you please elaborate what do you mean by
> > hibernation assumes 'the memory layout' after resume be the same as that
> > before sleep?
> >
> > I don't understand how updating random_kmalloc_seed breaks resuming from
> > hibernation. Changing random_kmalloc_seed affects which kmalloc caches
> > newly allocated objects are from, but it should not affect the objects that are
> > already allocated (before hibernation).
>
> When resuming, the booting kernel should switch to the target kernel,
> if the address of switch code (from the booting kernel) is the
> effective data of the target kernel, then the switch code may be
> overwritten.

Hmm... I'm still missing some pieces.
How is the kernel binary overwritten when slab allocations are randomized? 

Also, I'm not sure if it's even safe to assume that the memory layout is the
same across boots. But I'm not an expert on swsusp anyway...

It'd be really helpful for linux-pm folks to clarify 1) what are the
(architecture-independent) assumptions are for swsusp to work, and
2) how architectures dealt with other randomization features like kASLR... 

> For LoongArch there is an additional problem: the regular kernel
> function uses absolute address to call exception handlers, this means
> the code calls to exception handlers should at the same address for
> booting kernel and target kernel.

-- 
Harry