On Mon, Nov 11, 2013 at 10:31 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * 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? 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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html