lkml.org 
[lkml]   [2013]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [tip:x86/kaslr] x86, kaslr: Provide randomness functions
From
On Mon, Nov 11, 2013 at 10:31 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
>>
>> * 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?

Ah, excellent suggestion. There's no reason they couldn't be. I can
rework that function to do that.

>> 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 seemed like those things didn't contribute as much entropy as the 3
already in use, but I could investigate how to distill those things
down into entropy. Perhaps just XORing the start and length of every
e820 area? DMI I'll need to dig into...

>> 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 ...

Fair point. Is memory layout and DMI used for system entropy later in boot?

> 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.)

Ah! Yes, thanks for catching that. I will fix that.

> 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?

Yeah, true -- that seems like a good place to describe the limits.

Would you like the series updated, or patches on top?

--
Kees Cook
Chrome OS Security


\
 
 \ /
  Last update: 2013-11-11 20:41    [W:0.210 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site