From: Alexander Potapenko <glider@google.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>
Cc: Christoph Lameter <cl@linux.com>,
Dmitry Vyukov <dvyukov@google.com>,
James Morris <jmorris@namei.org>, Jann Horn <jannh@google.com>,
Kostya Serebryany <kcc@google.com>,
Laura Abbott <labbott@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Matthew Wilcox <willy@infradead.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Randy Dunlap <rdunlap@infradead.org>,
Sandeep Patil <sspatil@android.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
Souptick Joarder <jrdr.linux@gmail.com>,
Marco Elver <elver@google.com>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
Date: Mon, 3 Jun 2019 11:24:49 +0200 [thread overview]
Message-ID: <CAG_fn=XBq-ipvZng3hEiGwyQH2rRNFbN_Cj0r+5VoJqou0vovA@mail.gmail.com> (raw)
In-Reply-To: <20190531181832.e7c3888870ce9e50db9f69e6@linux-foundation.org>
On Sat, Jun 1, 2019 at 3:18 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 29 May 2019 14:38:11 +0200 Alexander Potapenko <glider@google.com> wrote:
>
> > Print the currently enabled stack and heap initialization modes.
> >
> > The possible options for stack are:
> > - "all" for CONFIG_INIT_STACK_ALL;
> > - "byref_all" for CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL;
> > - "byref" for CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF;
> > - "__user" for CONFIG_GCC_PLUGIN_STRUCTLEAK_USER;
> > - "off" otherwise.
> >
> > Depending on the values of init_on_alloc and init_on_free boottime
> > options we also report "heap alloc" and "heap free" as "on"/"off".
>
> Why?
>
> Please fully describe the benefit to users so that others can judge the
> desirability of the patch. And so they can review it effectively, etc.
I'm going to update the description with the following passage:
Print the currently enabled stack and heap initialization modes.
Stack initialization is enabled by a config flag, while heap
initialization is configured at boot time with defaults being set
in the config. It's more convenient for the user to have all information
about these hardening measures in one place.
Does this make sense?
> Always!
>
> > In the init_on_free mode initializing pages at boot time may take some
> > time, so print a notice about that as well.
>
> How much time?
I've seen pauses up to 1 second, not actually sure they're worth a
separate line in the log.
Kees, how long were the delays in your case?
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
next prev parent reply other threads:[~2019-06-03 9:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190529123812.43089-1-glider@google.com>
2019-05-29 12:38 ` [PATCH v5 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options Alexander Potapenko
2019-05-29 18:41 ` Kees Cook
2019-05-29 12:38 ` [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time Alexander Potapenko
2019-05-29 18:43 ` Kees Cook
2019-06-01 1:18 ` Andrew Morton
2019-06-03 9:24 ` Alexander Potapenko [this message]
2019-06-04 3:14 ` Kees Cook
2019-06-04 6:01 ` Kaiwan N Billimoria
2019-06-04 15:06 ` Alexander Potapenko
2019-06-05 2:58 ` Kaiwan N Billimoria
2019-05-29 12:38 ` [PATCH v5 3/3] lib: introduce test_meminit module Alexander Potapenko
2019-05-29 18:47 ` 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='CAG_fn=XBq-ipvZng3hEiGwyQH2rRNFbN_Cj0r+5VoJqou0vovA@mail.gmail.com' \
--to=glider@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=jrdr.linux@gmail.com \
--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=willy@infradead.org \
--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