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 11:32:53 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/kaslr] x86, kaslr: Provide randomness functions

On Mon, Nov 11, 2013 at 10:31 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * 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?

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