You are not logged in.
I was going through the GRUB2 parameters where I came across the following 4 parameters to harden page allocation in the kernel
1) page_poison: Page poisoning flag.
2) slub_debug: Slub poisoning flag.
3) init_on_free
4) init_on_alloc
After doing some research I found out that init_on_alloc and init_on_free were introduced in 2019 after some persistent badgering by Linux users. According to the documentation of both of these parameters
Both init_on_alloc=1 and init_on_free=1 guarantee that the allocator returns zeroed memory. The two exceptions are slab caches with constructors and SLAB_TYPESAFE_BY_RCU flag. Those are never zero-initialized to preserve their semantics.
....
....
If either SLUB poisoning or page poisoning is enabled, we disable init_on_alloc and init_on_free so that initialization doesn't interfere with debugging.
From the documentation it appears that the choice is between using init_on_alloc/init_on_free or slub_debug/page_poison. Going by the documentation it is an either-or option. We cannot mix and match. So for example if we were to use slub_debug alone along with init_on_* then it would still disable the init_on_* parameters. The same thing happens if we use only page_poison along with the init_on_* parameters.
This had led to various distros, llike VoidLinux, Tails and others to prioritize init_on_free and init_on_alloc. On the other hand some other independent standards, as recent as 2022, that prioritize setting the page_poison parameter over init_on_* parameters. So guidance is not clear cut or uniform
I have the following queries on this
1) Does having all 4 of the above mentioned parameters in GRUB actually lead to init_on_alloc and init_on_free being ignored with only page_poison and slub_debug being used by the kernel?
2) What would be preferred mechanism? Going with init_on_alloc and init_on_free OR going with slub_debug and page_poison?
3) Are there some scenarios where page_poison/slub_debug would be preferred over init_on_free/init_on_alloc?
4) According to documentation the parameters init_on_* do not touch slab caches. Is there some way in which slab caches, when they are released, can be poisoned too or values zeroed out, especially if we are using init_on_* parameters?
Offline