public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Dan Rosenberg <drosenberg@vsecurity.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Tony Luck <tony.luck@gmail.com>,
	linux-kernel@vger.kernel.org, davej@redhat.com,
	kees.cook@canonical.com, davem@davemloft.net, eranian@google.com,
	adobriyan@gmail.com, penberg@kernel.org,
	Arjan van de Ven <arjan@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Valdis.Kletnieks@vt.edu, pageexec@freemail.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot
Date: Fri, 27 May 2011 19:38:35 +0200	[thread overview]
Message-ID: <20110527173835.GF4356@elte.hu> (raw)
In-Reply-To: <BANLkTin=VV_1rny+5EgwJXj1SQ45c2KKsw@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> That's the _only_ difference, and it's trivial and irrelevant. Come 
> up with something more real, please.

The advantages of dynamic per boot kernel randomization, over static 
per system randomization, as i see them, in order of descending 
importance:

 - A root exploit will still not give away the location of the
   kernel (assuming module loading has been disabled after bootup),
   so a rootkit cannot be installed 'silently' on the system, into
   RAM only, evading most offline-storage-checking tools.

   With static linking this is not possible: reading the kernel image
   as root trivially exposes the kernel's location.

 - We can expose RIPs to unprivileged tools. Certain users could
   still kernel-profile a busy server box while neither being root,
   nor having access to the real location of the kernel.

   With static linking this is not possible.

 - Crash & reboot & retry brute force exploits get harder: if one
   attempt at an exploit causes a crash and a reboot, the kernel
   addresses are different after the reboot so the attempt has to be
   retried without the advantage of any prior history.

   With static linking this kind of exploit is somewhat easier: every
   crash gives a permanent proof that the guessed RIP offet was
   wrong, so history can be used on subsequent retries.

 - It gives a way to go one step further in secure server lockdown:
   where even root with full access to all storage has no way to
   break into the kernel. Reboots, module loading and kexec can be
   controlled, ioperm() and iopl() can be restricted. If those are
   taken away then even if a root exploit allows the attacker to
   overwrite the kernel image, a reboot has to be waited for and if
   reboots do sanity checks [based on immutable storage] of the
   system then the exploit can be found.

   With static linking this is not possible: reading the kernel image
   as root trivially exposes the kernel's location.

It's in order of importance: you probably stopped caring at item 2 or 
3 but there's definitely people who'd like to go all the way to 4. So 
if we can do dynamic randomization sanely then why not offer it as an 
option?

Thanks,

	Ingo

  reply	other threads:[~2011-05-27 17:38 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24 20:31 [RFC][PATCH] Randomize kernel base address on boot Dan Rosenberg
2011-05-24 21:02 ` Ingo Molnar
2011-05-24 22:55   ` Dan Rosenberg
2011-05-24 21:16 ` Ingo Molnar
2011-05-24 23:00   ` Dan Rosenberg
2011-05-25 11:23     ` Ingo Molnar
2011-05-25 14:20       ` Dan Rosenberg
2011-05-25 14:29         ` Ingo Molnar
2011-05-24 23:06   ` H. Peter Anvin
2011-05-25 14:03     ` Dan Rosenberg
2011-05-25 14:14       ` Ingo Molnar
2011-05-25 15:48       ` H. Peter Anvin
2011-05-25 16:15         ` Dan Rosenberg
2011-05-25 16:24           ` H. Peter Anvin
2011-05-24 21:46 ` Brian Gerst
2011-05-24 23:01   ` Dan Rosenberg
2011-05-24 22:31 ` H. Peter Anvin
2011-05-24 23:04   ` Dan Rosenberg
2011-05-24 23:07     ` H. Peter Anvin
2011-05-24 23:34       ` Dan Rosenberg
2011-05-24 23:36         ` H. Peter Anvin
2011-05-24 23:14   ` H. Peter Anvin
2011-05-24 23:08 ` Dan Rosenberg
2011-05-25  2:05   ` Dan Rosenberg
2011-05-26 20:01 ` Vivek Goyal
2011-05-26 20:06   ` Dan Rosenberg
2011-05-26 20:16   ` Valdis.Kletnieks
2011-05-26 20:31     ` Vivek Goyal
2011-05-27  9:36       ` Ingo Molnar
2011-05-26 20:35 ` Vivek Goyal
2011-05-26 20:40   ` Vivek Goyal
2011-05-26 20:44     ` Dan Rosenberg
2011-05-26 20:55       ` Vivek Goyal
2011-05-27  9:38         ` Ingo Molnar
2011-05-27 13:07           ` Vivek Goyal
2011-05-27 13:38             ` Ingo Molnar
2011-05-27 13:13       ` Vivek Goyal
2011-05-27 13:21         ` Dan Rosenberg
2011-05-27 13:46           ` Ingo Molnar
2011-05-27 13:50           ` Vivek Goyal
2011-05-26 20:39 ` Dan Rosenberg
2011-05-27  7:15   ` Ingo Molnar
2011-05-31 16:52   ` Matthew Garrett
2011-05-31 18:40     ` H. Peter Anvin
2011-05-31 18:51       ` Matthew Garrett
2011-05-31 19:03         ` Dan Rosenberg
2011-05-31 19:07           ` H. Peter Anvin
2011-05-31 19:50           ` Ingo Molnar
2011-05-31 19:55           ` Ingo Molnar
2011-05-31 20:15             ` H. Peter Anvin
2011-05-31 20:27               ` Ingo Molnar
2011-05-31 20:30                 ` H. Peter Anvin
2011-06-01  6:18                   ` Ingo Molnar
2011-06-01 15:44                     ` H. Peter Anvin
2011-05-31 20:17             ` Dan Rosenberg
2011-05-26 22:18 ` Rafael J. Wysocki
2011-05-26 22:32   ` H. Peter Anvin
2011-05-27  0:26     ` Dan Rosenberg
2011-05-27 16:21       ` Rafael J. Wysocki
2011-05-27  2:45     ` Dave Jones
2011-05-27  9:40       ` Ingo Molnar
2011-05-27 16:11         ` Rafael J. Wysocki
2011-05-27 16:07     ` Rafael J. Wysocki
2011-05-27 15:42   ` Linus Torvalds
2011-05-27 16:11     ` Dan Rosenberg
2011-05-27 17:00     ` Ingo Molnar
2011-05-27 17:06       ` H. Peter Anvin
2011-05-27 17:10       ` Dan Rosenberg
2011-05-27 17:13         ` H. Peter Anvin
2011-05-27 17:16           ` Linus Torvalds
2011-05-27 17:38             ` Ingo Molnar [this message]
2011-05-27 17:20           ` Kees Cook
2011-05-27 17:16         ` Ingo Molnar
2011-05-27 17:21           ` Linus Torvalds
2011-05-27 17:46             ` Ingo Molnar
2011-05-27 17:53               ` H. Peter Anvin
2011-05-27 18:05                 ` Linus Torvalds
2011-05-27 19:15                   ` Vivek Goyal
2011-05-27 21:37                   ` H. Peter Anvin
2011-05-27 23:51                     ` H. Peter Anvin
2011-05-28 12:18                   ` Ingo Molnar
2011-05-29  1:13                     ` H. Peter Anvin
2011-05-29 12:47                       ` Ingo Molnar
2011-05-29 18:19                         ` H. Peter Anvin
2011-05-29 18:44                           ` Ingo Molnar
2011-05-29 18:52                             ` H. Peter Anvin
2011-05-29 19:56                               ` Ingo Molnar
2011-05-27 17:57               ` Linus Torvalds
2011-05-27 18:17                 ` Ingo Molnar
2011-05-27 18:43                   ` Kees Cook
2011-05-27 18:48                   ` david
2011-05-27 21:51                   ` Olivier Galibert
2011-05-27 22:11                     ` Valdis.Kletnieks
2011-05-28  0:50                     ` H. Peter Anvin
2011-05-28  6:32                     ` Ingo Molnar

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=20110527173835.GF4356@elte.hu \
    --to=mingo@elte.hu \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=davej@redhat.com \
    --cc=davem@davemloft.net \
    --cc=drosenberg@vsecurity.com \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=kees.cook@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pageexec@freemail.hu \
    --cc=penberg@kernel.org \
    --cc=rjw@sisk.pl \
    --cc=tony.luck@gmail.com \
    --cc=torvalds@linux-foundation.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