* init_on_alloc/init_on_free boot options @ 2020-08-19 22:18 Jirka Hladky 2020-08-19 23:36 ` Kees Cook 0 siblings, 1 reply; 3+ messages in thread From: Jirka Hladky @ 2020-08-19 22:18 UTC (permalink / raw) To: Alexander Potapenko; +Cc: kernel-hardening, linux-mm, linux-security-module Hi Alex, Could you please help me to clarify the purpose of init_on_alloc=1 when init_on_free is enabled? If I get it right, init_on_free=1 alone guarantees that the memory returned by the page allocator and SL[AU]B is initialized with zeroes. What is the purpose of init_on_alloc=1 in that case? We are zeroing memory twice, or am I missing something? Thanks a lot! Jirka ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: init_on_alloc/init_on_free boot options 2020-08-19 22:18 init_on_alloc/init_on_free boot options Jirka Hladky @ 2020-08-19 23:36 ` Kees Cook 2020-08-20 0:35 ` Jirka Hladky 0 siblings, 1 reply; 3+ messages in thread From: Kees Cook @ 2020-08-19 23:36 UTC (permalink / raw) To: Jirka Hladky Cc: Alexander Potapenko, kernel-hardening, linux-mm, linux-security-module On Thu, Aug 20, 2020 at 12:18:33AM +0200, Jirka Hladky wrote: > Could you please help me to clarify the purpose of init_on_alloc=1 > when init_on_free is enabled? It's to zero memory at allocation time. :) (They are independent options.) > If I get it right, init_on_free=1 alone guarantees that the memory > returned by the page allocator and SL[AU]B is initialized with zeroes. No, it's guarantees memory freed by the page/slab allocators are zeroed. > What is the purpose of init_on_alloc=1 in that case? We are zeroing > memory twice, or am I missing something? If you have both enabled, yes, you will zero twice. (In theory, if you have any kind of Use-After-Free/dangling pointers that get written through after free and before alloc, those contents wouldn't strictly be zero at alloc time without init_on_alloc. But that's pretty rare. I wouldn't expect many people to run with both options enabled; init_on_alloc is more performance-friendly (i.e. cache-friendly), and init_on_free minimizes the lifetime of stale data in memory. It appears that the shipping kernel defaults for several distros (Ubuntu, Arch, Debian, others?) and devices (Android, Chrome OS, others?) are using init_on_alloc=1. Will Fedora and/or RedHat be joining this trend? :) -- Kees Cook ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: init_on_alloc/init_on_free boot options 2020-08-19 23:36 ` Kees Cook @ 2020-08-20 0:35 ` Jirka Hladky 0 siblings, 0 replies; 3+ messages in thread From: Jirka Hladky @ 2020-08-20 0:35 UTC (permalink / raw) To: Kees Cook Cc: Alexander Potapenko, kernel-hardening, linux-mm, linux-security-module Thanks a lot for the clarification! I was scratching my head if it makes sense to enable both options simultaneously. On Thu, Aug 20, 2020 at 1:36 AM Kees Cook <keescook@chromium.org> wrote: > > On Thu, Aug 20, 2020 at 12:18:33AM +0200, Jirka Hladky wrote: > > Could you please help me to clarify the purpose of init_on_alloc=1 > > when init_on_free is enabled? > > It's to zero memory at allocation time. :) (They are independent > options.) > > > If I get it right, init_on_free=1 alone guarantees that the memory > > returned by the page allocator and SL[AU]B is initialized with zeroes. > > No, it's guarantees memory freed by the page/slab allocators are zeroed. > > > What is the purpose of init_on_alloc=1 in that case? We are zeroing > > memory twice, or am I missing something? > > If you have both enabled, yes, you will zero twice. (In theory, if you > have any kind of Use-After-Free/dangling pointers that get written > through after free and before alloc, those contents wouldn't strictly be > zero at alloc time without init_on_alloc. But that's pretty rare. > > I wouldn't expect many people to run with both options enabled; > init_on_alloc is more performance-friendly (i.e. cache-friendly), and > init_on_free minimizes the lifetime of stale data in memory. > > It appears that the shipping kernel defaults for several distros (Ubuntu, > Arch, Debian, others?) and devices (Android, Chrome OS, others?) are using > init_on_alloc=1. Will Fedora and/or RedHat be joining this trend? :) > > -- > Kees Cook > -- -Jirka ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-08-20 0:35 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-19 22:18 init_on_alloc/init_on_free boot options Jirka Hladky 2020-08-19 23:36 ` Kees Cook 2020-08-20 0:35 ` Jirka Hladky
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).