All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: hpa@zytor.com, linux-kernel@vger.kernel.org,
	keescook@chromium.org, tglx@linutronix.de, hpa@linux.intel.com
Cc: linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/kaslr] x86, kaslr: Provide randomness functions
Date: Mon, 11 Nov 2013 19:20:46 +0100	[thread overview]
Message-ID: <20131111182046.GA14961@gmail.com> (raw)
In-Reply-To: <tip-5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3@git.kernel.org>


* tip-bot for Kees Cook <tipbot@zytor.com> wrote:

> Commit-ID:  5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> Gitweb:     http://git.kernel.org/tip/5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> Author:     Kees Cook <keescook@chromium.org>
> AuthorDate: Thu, 10 Oct 2013 17:18:15 -0700
> Committer:  H. Peter Anvin <hpa@linux.intel.com>
> CommitDate: Sun, 13 Oct 2013 03:12:12 -0700
> 
> x86, kaslr: Provide randomness functions
> 
> Adds potential sources of randomness: RDRAND, RDTSC, or the i8254.
> 
> This moves the pre-alternatives inline rdrand function into the header so
> both pieces of code can use it. Availability of RDRAND is then controlled
> by CONFIG_ARCH_RANDOM, if someone wants to disable it even for kASLR.

While reviewing this as a pre-pull-request, I noticed the following 
detail:

> +static unsigned long get_random_long(void)
> +{
> +	unsigned long random;
> +
> +	if (has_cpuflag(X86_FEATURE_RDRAND)) {
> +		debug_putstr("KASLR using RDRAND...\n");
> +		if (rdrand_long(&random))
> +			return random;
> +	}
> +
> +	if (has_cpuflag(X86_FEATURE_TSC)) {
> +		uint32_t raw;
> +
> +		debug_putstr("KASLR using RDTSC...\n");
> +		rdtscl(raw);
> +
> +		/* Only use the low bits of rdtsc. */
> +		random = raw & 0xffff;
> +	} else {
> +		debug_putstr("KASLR using i8254...\n");
> +		random = i8254();
> +	}
> +
> +	/* Extend timer bits poorly... */
> +	random |= (random << 16);
> +#ifdef CONFIG_X86_64
> +	random |= (random << 32);
> +#endif
> +	return random;
> +}

Why aren't the 3 sources of entropy XOR-ed together?

Also, we talked about also adding system dependent entropy sources, such 
as memory layout or the DMI table - none of that seems to have happened.

It's not like this function should be performance critical, it's run once 
per bootup, right? There's just no excuse for not maximizing available 
entropy in such a situation ...

Thanks,

	Ingo

  reply	other threads:[~2013-11-11 18:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-11  0:18 [PATCH v8 0/6] Kernel base address randomization Kees Cook
2013-10-11  0:18 ` [kernel-hardening] " Kees Cook
2013-10-11  0:18 ` [PATCH v8 1/6] x86, boot: move CPU flags out of cpucheck Kees Cook
2013-10-11  0:18   ` [kernel-hardening] " Kees Cook
2013-10-13 12:01   ` [tip:x86/kaslr] x86, boot: Move " tip-bot for Kees Cook
2013-10-13 12:02   ` [tip:x86/kaslr] x86, boot: Rename get_flags() and check_flags() to *_cpuflags() tip-bot for H. Peter Anvin
2013-10-11  0:18 ` [PATCH v8 2/6] x86, kaslr: return location from decompress_kernel Kees Cook
2013-10-11  0:18   ` [kernel-hardening] " Kees Cook
2013-10-13 12:01   ` [tip:x86/kaslr] x86, kaslr: Return " tip-bot for Kees Cook
2013-10-11  0:18 ` [PATCH v8 3/6] x86, kaslr: provide randomness functions Kees Cook
2013-10-11  0:18   ` [kernel-hardening] " Kees Cook
2013-10-13 12:01   ` [tip:x86/kaslr] x86, kaslr: Provide " tip-bot for Kees Cook
2013-11-11 18:20     ` Ingo Molnar [this message]
2013-11-11 18:31       ` Ingo Molnar
2013-11-11 19:32         ` Kees Cook
2013-11-11 19:37           ` H. Peter Anvin
2013-11-11 20:07             ` Ingo Molnar
2013-11-11 20:11               ` Kees Cook
2013-11-11 20:16                 ` H. Peter Anvin
2013-11-11 19:27       ` H. Peter Anvin
2013-11-11 19:37         ` Kees Cook
2013-11-11 19:42           ` H. Peter Anvin
2013-11-11 19:58             ` Ingo Molnar
2013-11-11 20:04               ` H. Peter Anvin
2013-11-11 20:09                 ` Ingo Molnar
2013-11-13 18:16       ` Pavel Machek
2013-11-13 18:40         ` H. Peter Anvin
2013-11-13 23:23           ` Pavel Machek
2013-11-13 23:25             ` H. Peter Anvin
2013-10-11  0:18 ` [PATCH v8 4/6] x86, kaslr: select random position from e820 maps Kees Cook
2013-10-11  0:18   ` [kernel-hardening] " Kees Cook
2013-10-13 12:01   ` [tip:x86/kaslr] x86, kaslr: Select " tip-bot for Kees Cook
2013-10-11  0:18 ` [PATCH v8 5/6] x86, kaslr: report kernel offset on panic Kees Cook
2013-10-11  0:18   ` [kernel-hardening] " Kees Cook
2013-10-13 12:01   ` [tip:x86/kaslr] x86, kaslr: Report " tip-bot for Kees Cook
2013-10-11  0:18 ` [PATCH v8 6/6] x86, kaslr: raise max positions to 1GiB on x86_64 Kees Cook
2013-10-11  0:18   ` [kernel-hardening] " Kees Cook
2013-10-13 12:02   ` [tip:x86/kaslr] x86, kaslr: Raise the maximum virtual address to -1 GiB " tip-bot for 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=20131111182046.GA14961@gmail.com \
    --to=mingo@kernel.org \
    --cc=hpa@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.