From: Alexander Potapenko <glider@google.com>
To: akpm@linux-foundation.org, cl@linux.com, keescook@chromium.org
Cc: kernel-hardening@lists.openwall.com, linux-mm@kvack.org,
linux-security-module@vger.kernel.org
Subject: [PATCH v4 0/3] RFC: add init_on_alloc/init_on_free boot options
Date: Thu, 23 May 2019 16:08:41 +0200 [thread overview]
Message-ID: <20190523140844.132150-1-glider@google.com> (raw)
Provide init_on_alloc and init_on_free boot options.
These are aimed at preventing possible information leaks and making the
control-flow bugs that depend on uninitialized values more deterministic.
Enabling either of the options guarantees that the memory returned by the
page allocator and SL[AOU]B is initialized with zeroes.
Enabling init_on_free also guarantees that pages and heap objects are
initialized right after they're freed, so it won't be possible to access
stale data by using a dangling pointer.
As suggested by Michal Hocko, right now we don't let the heap users to
disable initialization for certain allocations. There's not enough
evidence that doing so can speed up real-life cases, and introducing
ways to opt-out may result in things going out of control.
Alexander Potapenko (3):
mm: security: introduce init_on_alloc=1 and init_on_free=1 boot
options
mm: init: report memory auto-initialization features at boot time
lib: introduce test_meminit module
.../admin-guide/kernel-parameters.txt | 8 +
drivers/infiniband/core/uverbs_ioctl.c | 2 +-
include/linux/mm.h | 22 ++
init/main.c | 24 ++
kernel/kexec_core.c | 2 +-
lib/Kconfig.debug | 8 +
lib/Makefile | 1 +
lib/test_meminit.c | 208 ++++++++++++++++++
mm/dmapool.c | 2 +-
mm/page_alloc.c | 63 +++++-
mm/slab.c | 16 +-
mm/slab.h | 16 ++
mm/slob.c | 22 +-
mm/slub.c | 27 ++-
net/core/sock.c | 2 +-
security/Kconfig.hardening | 14 ++
16 files changed, 416 insertions(+), 21 deletions(-)
create mode 100644 lib/test_meminit.c
---
v3: dropped __GFP_NO_AUTOINIT patches
--
2.21.0.1020.gf2820cf01a-goog
next reply other threads:[~2019-05-23 14:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 14:08 Alexander Potapenko [this message]
2019-05-23 14:08 ` [PATCH v4 0/3] RFC: add init_on_alloc/init_on_free boot options Alexander Potapenko
2019-05-23 14:08 ` [PATCH v4 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 " Alexander Potapenko
2019-05-23 14:08 ` Alexander Potapenko
2019-05-24 0:04 ` Kees Cook
2019-05-23 14:08 ` [PATCH v4 2/3] mm: init: report memory auto-initialization features at boot time Alexander Potapenko
2019-05-23 14:08 ` Alexander Potapenko
2019-05-23 14:08 ` [PATCH v4 3/3] lib: introduce test_meminit module Alexander Potapenko
2019-05-23 14:08 ` Alexander Potapenko
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=20190523140844.132150-1-glider@google.com \
--to=glider@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=keescook@chromium.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.