On 2/16/25 06:08, Huacai Chen wrote:
On Sat, Feb 15, 2025 at 10:05 PM Harry (Hyeonggon) Yoo 42.hyeyoo@gmail.com wrote:
You mean when SLAB_FREELIST_RANDOM enabled? Assuming that...
Yes.
the CPU1's idle task stack from the booting kernel may be the CPU2's idle task stack from the target kernel, and CPU2's idle task stack from the booting kernel may be the CPU1's idle task stack from the target kernel
The freelist can have more objects than the number of cpus and then it's not just exchanging stacks between cpus but also with whatever else allocates from the same slab.
What happens if it's not the case?
SLAB means "objects with the same type", right? So it is probably the
kmalloc() is not objects of the same type, just size
case. Yes, there is a very very low possibility that not the case, but...
In theory x86_64 also has a low possibility that the idle task's stack or other metadata be overwritten, then should we also disable random kmalloc for x86_64?
Does x86 really have such possibility? Can you explain in more detail?
On the other hand, if we really need to handle this theoretic possibility about SLAB_FREELIST_RANDOM now, we can simply move init_freelist_randomization() after all initcalls, too.
I think a more robust approach would be to make sure any allocations critical for hibernation/resume are static? Are there really multiple CPU's idle task stacks involved? Aren't the critical paths single cpu only? I'd assume when multiple cpus might be running at that phase, all bets about determinism are off? So there could be a statically allocated stack for the single cpu?
Note I don't know much about how hibernation works. But it seems fragile to rely on rather complex allocators (slab over page allocators) to give me exactly the same addresses accross boots, and hack around their randomization features to help with that, if there's an alternative to use static allocations for the critical pieces of the hibernation/resume code.
Huacai
but idle task's stack from the booting kernel won't be other things from the target kernel (and won't be overwritten by switching kernel).
What guarantees that it won't be overwritten? To me it seems to be a fragile assumption that could be broken.
Am I missing something?
-- Harry