All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: Kees Cook <keescook@chromium.org>, rick.p.edgecombe@intel.com
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	kristen.c.accardi@intel.com, Dave Hansen <dave.hansen@intel.com>,
	arjan.van.de.ven@intel.com
Subject: Re: [PATCH 0/3] KASLR feature to randomize each loadable module
Date: Thu, 21 Jun 2018 15:39:03 +0200	[thread overview]
Message-ID: <CAG48ez1eAKVy13tmAxrVkRqj2Fd+wduqBt4fzMBjY5FA1aFFmw@mail.gmail.com> (raw)
In-Reply-To: <CAG48ez2uuQkSS9DLz6j5HbpuxaHMyAVYGMM+xoZEo51N=sHmdg@mail.gmail.com>

On Thu, Jun 21, 2018 at 3:37 PM Jann Horn <jannh@google.com> wrote:
>
> On Thu, Jun 21, 2018 at 12:34 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Wed, Jun 20, 2018 at 3:09 PM, Rick Edgecombe
> > <rick.p.edgecombe@intel.com> wrote:
> > > This patch changes the module loading KASLR algorithm to randomize the position
> > > of each module text section allocation with at least 18 bits of entropy in the
> > > typical case. It used on x86_64 only for now.
> >
> > Very cool! Thanks for sending the series. :)
> >
> > > Today the RANDOMIZE_BASE feature randomizes the base address where the module
> > > allocations begin with 10 bits of entropy. From here, a highly deterministic
> > > algorithm allocates space for the modules as they are loaded and un-loaded. If
> > > an attacker can predict the order and identities for modules that will be
> > > loaded, then a single text address leak can give the attacker access to the
> >
> > nit: "text address" -> "module text address"
> >
> > > So the defensive strength of this algorithm in typical usage (<800 modules) for
> > > x86_64 should be at least 18 bits, even if an address from the random area
> > > leaks.
> >
> > And most systems have <200 modules, really. I have 113 on a desktop
> > right now, 63 on a server. So this looks like a trivial win.
[...]
> Also: What's the impact on memory usage? Is this going to increase the
> number of pagetables that need to be allocated by the kernel per
> module_alloc() by 4K or 8K or so?

Sorry, I meant increase the amount of memory used by pagetables by 4K
or 8K, not the number of pagetables.

  reply	other threads:[~2018-06-21 13:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 22:09 [PATCH 0/3] KASLR feature to randomize each loadable module Rick Edgecombe
2018-06-20 22:09 ` [PATCH 1/3] vmalloc: Add __vmalloc_node_try_addr function Rick Edgecombe
2018-06-20 22:16   ` Randy Dunlap
2018-06-20 22:35     ` Kees Cook
2018-06-20 22:44       ` Randy Dunlap
2018-06-20 23:05         ` Kees Cook
2018-06-20 23:16           ` Randy Dunlap
2018-06-20 22:26   ` Matthew Wilcox
2018-06-21 22:02     ` Edgecombe, Rick P
2018-06-21 22:02       ` Edgecombe, Rick P
2018-06-20 22:09 ` [PATCH 2/3] x86/modules: Increase randomization for modules Rick Edgecombe
2018-06-20 22:09 ` [PATCH 3/3] vmalloc: Add debugfs modfraginfo Rick Edgecombe
2018-06-21  0:53   ` kbuild test robot
2018-06-21  0:53     ` kbuild test robot
2018-06-21  1:17   ` kbuild test robot
2018-06-21  1:17     ` kbuild test robot
2018-06-21 12:32   ` Jann Horn
2018-06-21 18:56     ` Edgecombe, Rick P
2018-06-21 18:56       ` Edgecombe, Rick P
2018-06-20 22:33 ` [PATCH 0/3] KASLR feature to randomize each loadable module Kees Cook
2018-06-21 13:37   ` Jann Horn
2018-06-21 13:39     ` Jann Horn [this message]
2018-06-21 18:59     ` Edgecombe, Rick P
2018-06-21 18:59       ` Edgecombe, Rick P
2018-06-21 21:23       ` Daniel Borkmann
2018-06-21 21:23         ` Daniel Borkmann
2018-06-21 21:23         ` Daniel Borkmann
2018-06-21 18:56   ` Edgecombe, Rick P
2018-06-21 18:56     ` Edgecombe, Rick P

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=CAG48ez1eAKVy13tmAxrVkRqj2Fd+wduqBt4fzMBjY5FA1aFFmw@mail.gmail.com \
    --to=jannh@google.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kristen.c.accardi@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@linutronix.de \
    --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 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.