public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Jianguo Wu <wujianguo@huawei.com>, Andy Honig <ahonig@google.com>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH] x86, kaslr: randomize module base load address
Date: Fri, 21 Feb 2014 13:15:31 -0800	[thread overview]
Message-ID: <20140221131531.2db80023c59895a930cf374f@linux-foundation.org> (raw)
In-Reply-To: <CAGXu5jLGBJp7oKXjausV70bXF-RTVDXxdZriS0cJ7X6NO90Ybg@mail.gmail.com>

On Fri, 21 Feb 2014 13:05:08 -0800 Kees Cook <keescook@chromium.org> wrote:

> >> +#ifdef CONFIG_RANDOMIZE_BASE
> >> +static unsigned long module_load_offset;
> >> +static int randomize_modules = 1;
> >
> > It's pretty common for people to later come back and say "hey I want to
> > set the default in Kconfig".  Perhaps we should do that from day 1.
> 
> I've been slapped down for adding more config options in the past, and
> I think it's unlikely that people using CONFIG_RANDOMIZE_BASE won't
> want the modules base randomized too. I think this is a safe default,
> but if you see it as a requirement, I can change it.

I think there were issues with some embedded systems where it's
hard/impossible to provide/alter boot parameters.

I suppose we can leave it this way until there are complaints.

> > This implies that parse_nokaslr() will need to be renamed and taught to
> > handle 0->1 changing.
> >
> >> +static int __init parse_nokaslr(char *p)
> >> +{
> >> +     randomize_modules = 0;
> >> +     return 0;
> >> +}
> >> +early_param("nokaslr", parse_nokaslr);
> >
> > Documentation/kernel-parameters.txt, please.   This isn't hard :(
> 
> "nokaslr" is already documented. Do you mean adding a note about
> modules as well to the existing documentation?

Yes, it should now mention modules as well.

> >> +static unsigned long int get_module_load_offset(void)
> >> +{
> >> +     if (randomize_modules) {
> >> +             mutex_lock(&module_mutex);
> >> +             /*
> >> +              * Calculate the module_load_offset the first time this
> >> +              * code is called. Once calculated it stays the same until
> >> +              * reboot.
> >> +              */
> >> +             if (module_load_offset == 0)
> >> +                     module_load_offset =
> >> +                             (get_random_int() % 1024 + 1) * PAGE_SIZE;
> >> +             mutex_unlock(&module_mutex);
> >> +     }
> >> +     return module_load_offset;
> >> +}
> >
> > This seems unnecessarily complex and inefficient.  We only set
> > module_load_offset a single time, so why not do it that way?
> > Mark it __init, run it during initcalls then throw it away.
> 
> I'd like to make sure this is running well after the pRNG is up and
> running. I can run some tests to see how the entropy looks if this is
> done during __init, though.

That may be a bit optimistic, dunno.  I suppose that doing it this way
we will already have done a bit of disk IO, so there will be more
randomness.

btw, would it be better to make each module have its own offset rather
than using the same offset for all of them?  That could cause problems
with vmap space fragmentation I guess.

  parent reply	other threads:[~2014-02-21 21:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21 20:21 [PATCH] x86, kaslr: randomize module base load address Kees Cook
2014-02-21 20:36 ` Andrew Morton
2014-02-21 21:05   ` Kees Cook
2014-02-21 21:09     ` H. Peter Anvin
2014-02-21 21:15     ` Andrew Morton [this message]
2014-02-21 21:18       ` H. Peter Anvin
2014-02-21 21:27         ` Andrew Morton
2014-02-21 23:01           ` H. Peter Anvin
2014-02-21 21:21       ` 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=20140221131531.2db80023c59895a930cf374f@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ahonig@google.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=wujianguo@huawei.com \
    --cc=x86@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