Re: [tip:x86/kaslr] x86, kaslr: Provide randomness functions
From: Ingo Molnar
Date: Mon Nov 11 2013 - 13:31:15 EST
* 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/