From: Kees Cook <keescook@chromium.org>
To: Jirka Hladky <jhladky@redhat.com>
Cc: Alexander Potapenko <glider@google.com>,
kernel-hardening@lists.openwall.com, linux-mm@kvack.org,
linux-security-module@vger.kernel.org
Subject: Re: init_on_alloc/init_on_free boot options
Date: Wed, 19 Aug 2020 16:36:10 -0700 [thread overview]
Message-ID: <202008191626.1420C63231@keescook> (raw)
In-Reply-To: <CAE4VaGD8sKqUgOxr0im+OJgwrLxbbXDaKTSqpyAGRx=rr9isUg@mail.gmail.com>
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
next prev parent reply other threads:[~2020-08-19 23:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 22:18 Jirka Hladky
2020-08-19 23:36 ` Kees Cook [this message]
2020-08-20 0:35 ` Jirka Hladky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202008191626.1420C63231@keescook \
--to=keescook@chromium.org \
--cc=glider@google.com \
--cc=jhladky@redhat.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox