[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26238.1306534308@turing-police.cc.vt.edu>
Date: Fri, 27 May 2011 18:11:48 -0400
From: Valdis.Kletnieks@...edu
To: Olivier Galibert <galibert@...ox.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Dan Rosenberg <drosenberg@...curity.com>,
"Rafael J. Wysocki" <rjw@...k.pl>, Tony Luck <tony.luck@...il.com>,
linux-kernel@...r.kernel.org, davej@...hat.com,
kees.cook@...onical.com, davem@...emloft.net, eranian@...gle.com,
adobriyan@...il.com, penberg@...nel.org, hpa@...or.com,
Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>, pageexec@...email.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot
On Fri, 27 May 2011 23:51:23 +0200, Olivier Galibert said:
> On Fri, May 27, 2011 at 08:17:24PM +0200, Ingo Molnar wrote:
> > - 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.
>
> There's something I don't get there. If you managed to escalate your
> priviledges enough that you have physical ram access, there's a
> billion things you can do to find the kernel, including vector
> tracing, pattern matching, looking at the page tables, etc.
Oh, you mean all the tricks that people do now to patch the syscall table
once we hid it so they couldn't patch it? :)
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists