[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130405144954.GC29290@pd.tnic>
Date: Fri, 5 Apr 2013 16:49:54 +0200
From: Borislav Petkov <bp@...en8.de>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, 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 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...
[ … ]
> When built into the kernel, the "noaslr" kernel command line option
> will disable the feature.
... so the saner thing to do, IMHO, would be to flip the meaning of
this option to "kaslr" or whatever and let people and distros enable
randomization on kernels which are bug free and don't oops (good luck
finding those :-)). Generally make the thing opt-in instead of opt-out.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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.
