[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.00.1304051408540.23195@twin.jikos.cz>
Date: Fri, 5 Apr 2013 14:12:20 +0200 (CEST)
From: Jiri Kosina <jkosina@...e.cz>
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, 4 Apr 2013, Kees Cook wrote:
> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
> can be randomized at boot.
>
> This makes kernel vulnerabilities harder to reliably exploit, especially
> from remote attacks and local processes in seccomp containers. Keeping
> the location of kernel addresses secret becomes very important when using
> this feature, so enabling kptr_restrict and dmesg_restrict is recommended.
If we are going to take the KASLR path at all, and assuming this is done
purely because of security, I'd suggest not only vaguely mentioning this
requirement in the changelog (and calling it recommendation), but make it
a hard prerequisity.
Without kernel addresses being invisible to userspace, this feature is
completely useless, but might provide very false sense of security if just
blindly enabled by random Joe Bofh.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists