Date: Fri, 5 Apr 2013 13:19:39 -0700 From: Julien Tinnes <jln@...gle.com> To: Borislav Petkov <bp@...en8.de>, Kees Cook <keescook@...omium.org>, LKML <linux-kernel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "H. Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "x86@...nel.org" <x86@...nel.org>, Jarkko Sakkinen <jarkko.sakkinen@...el.com>, Matthew Garrett <mjg@...hat.com>, Matt Fleming <matt.fleming@...el.com>, Eric Northup <digitaleric@...gle.com>, Dan Rosenberg <drosenberg@...curity.com>, Julien Tinnes <jln@...gle.com>, Will Drewry <wad@...omium.org> Subject: Re: [PATCH 3/3] x86: kernel base offset ASLR On Fri, Apr 5, 2013 at 7:49 AM, Borislav Petkov <bp@...en8.de> wrote: > On Thu, Apr 04, 2013 at 01:07:35PM -0700, Kees Cook wrote: >> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel >> can be randomized at boot. > > Right, > > if I'm reading this whole deal correctly, I have an issue with this > in the sense that if this thing is enabled by default and people are > running stripped kernels, an oops which is being reported is worth sh*t > since all the addresses there are random and one simply can't map them > back to which functions the callstack frames are pointing to. Which will > majorly hinder debuggability, IMHO... I think it'd be perfectly ok for OOPS to print out the kernel base. Restricting access to these oopses becomes a different problem (privilege separation). Some existing sandboxes (Chromium, vsftpd, openssh..) are already defending against it. Julien
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.