linux-kernel - Re: [tip:x86/kaslr] x86, kaslr: Provide randomness functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Nov 2013 19:31:01 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	hpa@...or.com, linux-kernel@...r.kernel.org, keescook@...omium.org,
	tglx@...utronix.de, hpa@...ux.intel.com
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/kaslr] x86, kaslr: Provide randomness functions


* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * tip-bot for Kees Cook <tipbot@...or.com> wrote:
> 
> > Commit-ID:  5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> > Gitweb:     http://git.kernel.org/tip/5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> > Author:     Kees Cook <keescook@...omium.org>
> > AuthorDate: Thu, 10 Oct 2013 17:18:15 -0700
> > Committer:  H. Peter Anvin <hpa@...ux.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 ...

Another problem I noticed is that the RANDOMIZE_BASE Kconfig text does not 
match the actual sources of entropy:

           Entropy is generated using the RDRAND instruction if it
           is supported.  If not, then RDTSC is used, if supported. If
           neither RDRAND nor RDTSC are supported, then no randomness
           is introduced.

(i8254 is missing.)

Nor does the help text explain an important detail: what granularity does 
the randomization have and roughly how many bits of the address are 
randomized if people use the default values?

Thanks,

	Ingo
--
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/