public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "keescook@chromium.org" <keescook@chromium.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Accardi, Kristen C" <kristen.c.accardi@intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"Hansen, Dave" <dave.hansen@intel.com>
Subject: Re: [PATCH 0/3] KASLR feature to randomize each loadable module
Date: Thu, 21 Jun 2018 18:56:13 +0000	[thread overview]
Message-ID: <1529607389.29548.198.camel@intel.com> (raw)
In-Reply-To: <CAGXu5jLt8Zv-p=9J590WFppc3O6LWrAVdi-xtU7r_8f4j0XeRg@mail.gmail.com>

On Wed, 2018-06-20 at 15:33 -0700, Kees Cook wrote:
> > The new __vmalloc_node_try_addr function uses the existing function
> > __vmalloc_node_range, in order to introduce this algorithm with the
> > least
> > invasive change. The side effect is that each time there is a
> > collision when
> > trying to allocate in the random area a TLB flush will be
> > triggered. There is
> > a more complex, more efficient implementation that can be used
> > instead if
> > there is interest in improving performance.
> The only time when module loading speed is noticeable, I would think,
> would be boot time. Have you done any boot time delta analysis? I
> wouldn't expect it to change hardly at all, but it's probably a good
> idea to actually test it. :)

Thanks, I'll do some tests.

> Also: can this be generalized for use on other KASLRed architectures?
> For example, I know the arm64 module randomization is pretty similar
> to x86.

I started in the x86/kernel/module.c because that was where the
existing implementation was, but I don't know of any reason why
it could not apply to other architectures in general.

The randomness estimates would be different if module size probability
distribution, module space size or module alignment are different.


      parent reply	other threads:[~2018-06-21 18:56 UTC|newest]

Thread overview: 21+ 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-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  1:17   ` kbuild test robot
2018-06-21 12:32   ` Jann Horn
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
2018-06-21 18:59     ` Edgecombe, Rick P
2018-06-21 21:23       ` Daniel Borkmann
2018-06-21 18:56   ` Edgecombe, Rick P [this message]

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=1529607389.29548.198.camel@intel.com \
    --to=rick.p.edgecombe@intel.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox