From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
x86@kernel.org
Subject: Re: [PATCH] x86, kaslr: mix entropy sources together as needed
Date: Mon, 11 Nov 2013 21:57:43 +0100 [thread overview]
Message-ID: <20131111205743.GF18886@gmail.com> (raw)
In-Reply-To: <20131111204853.GA24459@www.outflux.net>
* Kees Cook <keescook@chromium.org> wrote:
> Depending on availability, mix the RDRAND and RDTSC entropy together with
> XOR. Only when neither is available should the i8254 be used. Update
> the Kconfig documentation to reflect this. Additionally, since bits
> used for entropy is masked elsewhere, drop the needless masking in the
> get_random_long().
>
> Finally, to improve the starting entropy, do a simple hashing of the
> boot_params structure for some additional level of unpredictability.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/x86/Kconfig | 14 +++++++----
> arch/x86/boot/compressed/aslr.c | 52 ++++++++++++++++++++++++++++-----------
> 2 files changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index ee3b38363063..119455802d57 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1736,13 +1736,17 @@ config RANDOMIZE_BASE
> deters exploit attempts relying on knowledge of the location
> of kernel internals.
>
> + Entropy is generated using the RDRAND instruction if it is
> + supported. If RDTSC is supported, it is used as well. If
> + neither RDRAND nor RDTSC are supported, then randomness is
> + read from the i8254 timer.
>
> The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET,
> + and aligned according to PHYSICAL_ALIGN. Since the kernel is
> + built using 2GiB addressing, and PHYSICAL_ALGIN must be at a
> + minimum of 2MiB, only 10 bits of entropy is theoretically
> + possible. At best, due to page table layouts, 64-bit can use
> + 9 bits of entropy and 32-bit uses 8 bits.
Perfect!
> +/* Simple way to create an alternate starting entropy. */
> +static unsigned long get_boot_hash(void)
s/get_random_boot, signifying that we want to get some initial randomness?
Btw., could we also add some build build time source of randomness as
well? That won't help distro kernels which all share the same build but it
would be a nice touch for self-built kernels and Gentoo systems.
> +{
> + int i;
> + unsigned long hash = 0;
> + unsigned long *ptr = (unsigned long *)real_mode;
> +
> + for (i = 0; i < sizeof(*real_mode) / sizeof(hash); i++) {
> + /* Rotate and XOR */
> + hash = (hash << ((sizeof(hash) - 1) * 8)) | (hash >> 8);
> + hash ^= ptr[i];
> + }
> +
> + return hash;
Looks mostly good, but I'm too tired to ack this bit now, maybe hpa will
have a look :-)
> +}
> +
> static unsigned long get_random_long(void)
> {
> + unsigned long random = get_boot_hash();
> + bool use_i8254 = true;
> +
> + debug_putstr("KASLR using");
>
> if (has_cpuflag(X86_FEATURE_RDRAND)) {
> + unsigned long raw;
> +
> + debug_putstr(" RDRAND");
> + if (rdrand_long(&raw)) {
> + random ^= raw;
> + use_i8254 = false;
> + }
> }
>
> if (has_cpuflag(X86_FEATURE_TSC)) {
> uint32_t raw;
>
> + debug_putstr(" RDTSC");
> rdtscl(raw);
>
> + random ^= raw;
> + use_i8254 = false;
The TSC is 64-bits. The high bits will most likely be 0, but just in case
there's some dirt up there or BIOS bootup takes more than 4G cycles we
might as well use the high portion as well!
> }
>
> + if (use_i8254) {
> + debug_putstr(" i8254");
> + random ^= i8254();
> + }
> +
> + debug_putstr("...\n");
> +
> return random;
> }
Looks good otherwise.
Thanks,
Ingo
next prev parent reply other threads:[~2013-11-11 20:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 20:48 [PATCH] x86, kaslr: mix entropy sources together as needed Kees Cook
2013-11-11 20:57 ` Ingo Molnar [this message]
2013-11-11 21:31 ` Kees Cook
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=20131111205743.GF18886@gmail.com \
--to=mingo@kernel.org \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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