Date: Fri, 17 May 2019 16:04:46 +0200 From: Michal Hocko <mhocko@...nel.org> To: Alexander Potapenko <glider@...gle.com> Cc: akpm@...ux-foundation.org, cl@...ux.com, keescook@...omium.org, kernel-hardening@...ts.openwall.com, Masahiro Yamada <yamada.masahiro@...ionext.com>, James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Nick Desaulniers <ndesaulniers@...gle.com>, Kostya Serebryany <kcc@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Sandeep Patil <sspatil@...roid.com>, Laura Abbott <labbott@...hat.com>, Randy Dunlap <rdunlap@...radead.org>, Jann Horn <jannh@...gle.com>, Mark Rutland <mark.rutland@....com>, linux-mm@...ck.org, linux-security-module@...r.kernel.org Subject: Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options On Tue 14-05-19 16:35:34, Alexander Potapenko wrote: > 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? -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.