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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> 
> * tip-bot for Kees Cook <tipbot@xxxxxxxxx> wrote:
> 
> > Commit-ID:  5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> > Gitweb:     http://git.kernel.org/tip/5bfce5ef55cbe78ee2ee6e97f2e26a8a582008f3
> > Author:     Kees Cook <keescook@xxxxxxxxxxxx>
> > AuthorDate: Thu, 10 Oct 2013 17:18:15 -0700
> > Committer:  H. Peter Anvin <hpa@xxxxxxxxxxxxxxx>
> > 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-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Stable Commits]     [Linux Stable Kernel]     [Linux Kernel]     [Linux USB Devel]     [Linux Video &Media]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux