From: Michal Hocko <mhocko@kernel.org>
To: Alexander Potapenko <glider@google.com>
Cc: akpm@linux-foundation.org, cl@linux.com, keescook@chromium.org,
kernel-hardening@lists.openwall.com,
Masahiro Yamada <yamada.masahiro@socionext.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Kostya Serebryany <kcc@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Sandeep Patil <sspatil@android.com>,
Laura Abbott <labbott@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
Jann Horn <jannh@google.com>, Mark Rutland <mark.rutland@arm.com>,
linux-mm@kvack.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
Date: Fri, 17 May 2019 16:04:46 +0200 [thread overview]
Message-ID: <20190517140446.GA8846@dhcp22.suse.cz> (raw)
In-Reply-To: <20190514143537.10435-2-glider@google.com>
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
next prev parent reply other threads:[~2019-05-17 14:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190514143537.10435-1-glider@google.com>
2019-05-14 14:35 ` [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options Alexander Potapenko
2019-05-16 16:19 ` Kees Cook
2019-05-16 16:42 ` Alexander Potapenko
2019-05-16 17:03 ` Kees Cook
2019-05-17 1:26 ` Kees Cook
2019-05-17 14:38 ` Alexander Potapenko
2019-05-17 14:04 ` Michal Hocko [this message]
2019-05-17 14:11 ` Alexander Potapenko
2019-05-17 14:20 ` Michal Hocko
2019-05-17 16:36 ` Kees Cook
2019-05-17 17:11 ` Michal Hocko
2019-05-14 14:35 ` [PATCH v2 2/4] lib: introduce test_meminit module Alexander Potapenko
2019-05-16 1:02 ` Kees Cook
2019-05-17 15:51 ` Alexander Potapenko
2019-05-17 16:37 ` Kees Cook
2019-05-14 14:35 ` [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT Alexander Potapenko
2019-05-17 12:59 ` Michal Hocko
2019-05-17 13:18 ` Alexander Potapenko
2019-05-17 13:25 ` Michal Hocko
2019-05-17 13:37 ` Alexander Potapenko
2019-05-17 14:01 ` Michal Hocko
2019-05-17 16:27 ` Kees Cook
2019-05-17 17:11 ` Michal Hocko
2019-05-21 14:18 ` Alexander Potapenko
2019-05-21 14:25 ` Michal Hocko
2019-05-14 14:35 ` [PATCH v2 4/4] net: apply __GFP_NO_AUTOINIT to AF_UNIX sk_buff allocations Alexander Potapenko
2019-05-16 16:53 ` Kees Cook
2019-05-17 0:26 ` Kees Cook
2019-05-17 8:49 ` Alexander Potapenko
2019-05-17 13:50 ` Alexander Potapenko
2019-05-17 16:13 ` Kees Cook
2019-05-17 0:50 ` [PATCH 5/4] mm: Introduce SLAB_NO_FREE_INIT and mark excluded caches Kees Cook
2019-05-17 8:34 ` Alexander Potapenko
2019-05-17 15:59 ` Kees Cook
2019-05-20 6:10 ` Mathias Krause
2019-05-20 16:12 ` Kees Cook
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=20190517140446.GA8846@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=kcc@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ndesaulniers@google.com \
--cc=rdunlap@infradead.org \
--cc=serge@hallyn.com \
--cc=sspatil@android.com \
--cc=yamada.masahiro@socionext.com \
/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;
as well as URLs for NNTP newsgroup(s).