On Fri 17-05-19 16:11:32, Alexander Potapenko wrote:

On Fri, May 17, 2019 at 4:04 PM Michal Hocko [off-list ref] wrote:

quoted

On Tue 14-05-19 16:35:34, Alexander Potapenko wrote:

quoted

The new options are needed to prevent possible information leaks and
make control-flow bugs that depend on uninitialized values more
deterministic.

init_on_alloc=1 makes the kernel initialize newly allocated pages and heap
objects with zeroes. Initialization is done at allocation time at the
places where checks for __GFP_ZERO are performed.

init_on_free=1 makes the kernel initialize freed pages and heap objects
with zeroes upon their deletion. This helps to ensure sensitive data
doesn't leak via use-after-free accesses.

Why do we need both? The later is more robust because even free memory
cannot be sniffed and the overhead might be shifted from the allocation
context (e.g. to RCU) but why cannot we stick to a single model?

init_on_free appears to be slower because of cache effects. It's
several % in the best case vs. <1% for init_on_alloc.

This doesn't really explain why we need both.
-- 
Michal Hocko
SUSE Labs