From: Michal Hocko <mhocko@kernel.org>
To: Alexander Potapenko <glider@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Kees Cook <keescook@chromium.org>,
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>,
Marco Elver <elver@google.com>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
Date: Fri, 21 Jun 2019 11:11:59 +0200 [thread overview]
Message-ID: <20190621091159.GD3429@dhcp22.suse.cz> (raw)
In-Reply-To: <CAG_fn=UFj0Lzy3FgMV_JBKtxCiwE03HVxnR8=f9a7=4nrUFXSw@mail.gmail.com>
On Fri 21-06-19 10:57:35, Alexander Potapenko wrote:
> On Fri, Jun 21, 2019 at 9:09 AM Michal Hocko <mhocko@kernel.org> wrote:
[...]
> > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > > index fd5c95ff9251..2f75dd0d0d81 100644
> > > --- a/kernel/kexec_core.c
> > > +++ b/kernel/kexec_core.c
> > > @@ -315,7 +315,7 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
> > > arch_kexec_post_alloc_pages(page_address(pages), count,
> > > gfp_mask);
> > >
> > > - if (gfp_mask & __GFP_ZERO)
> > > + if (want_init_on_alloc(gfp_mask))
> > > for (i = 0; i < count; i++)
> > > clear_highpage(pages + i);
> > > }
> >
> > I am not really sure I follow here. Why do we want to handle
> > want_init_on_alloc here? The allocated memory comes from the page
> > allocator and so it will get zeroed there. arch_kexec_post_alloc_pages
> > might touch the content there but is there any actual risk of any kind
> > of leak?
> You're right, we don't want to initialize this memory if init_on_alloc is on.
> We need something along the lines of:
> if (!static_branch_unlikely(&init_on_alloc))
> if (gfp_mask & __GFP_ZERO)
> // clear the pages
>
> Another option would be to disable initialization in alloc_pages() using a flag.
Or we can simply not care and keen the code the way it is. First of all
it seems that nobody actually does use __GFP_ZERO unless I have missed
soemthing
- kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order); # GFP_KERNEL | __GFP_NORETRY
- kimage_alloc_pages(gfp_mask, 0);
- kimage_alloc_page(image, GFP_KERNEL, KIMAGE_NO_DEST);
- kimage_alloc_page(image, GFP_HIGHUSER, maddr);
but even if we actually had a user do we care about double intialization
for something kexec related? It is not any hot path AFAIR.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-06-21 9:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 15:10 [PATCH v7 0/3] add init_on_alloc/init_on_free boot options Alexander Potapenko
2019-06-17 15:10 ` [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 " Alexander Potapenko
2019-06-17 22:10 ` Andrew Morton
2019-06-18 5:07 ` Kees Cook
2019-06-18 5:19 ` Andrew Morton
2019-06-18 5:26 ` Kees Cook
2019-06-21 7:09 ` Michal Hocko
2019-06-21 8:57 ` Alexander Potapenko
2019-06-21 9:11 ` Michal Hocko [this message]
2019-06-21 9:18 ` Alexander Potapenko
2019-06-21 14:10 ` Alexander Potapenko
2019-06-21 15:12 ` Michal Hocko
2019-06-21 15:24 ` Alexander Potapenko
2019-06-21 15:54 ` Michal Hocko
2019-06-21 12:36 ` Qian Cai
2019-06-21 13:31 ` Alexander Potapenko
2019-06-21 13:36 ` Qian Cai
2019-06-17 15:10 ` [PATCH v7 2/2] mm: init: report memory auto-initialization features at boot time 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=20190621091159.GD3429@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dvyukov@google.com \
--cc=elver@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 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.