lkml.org 
[lkml]   [2017]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: early x86 unseeded randomness
On Tue, 15 Aug 2017, Ingo Molnar wrote:
> * Willy Tarreau <w@1wt.eu> wrote:
>
> > Nowadays we could use similar methods using RDTSC providing more accurate
> > counting. This doesn't provide a lot of entropy of course, given that a
> > 2 GHz machine will at most count 31 bits there. But I tend to think that
> > what matters during early boot is to transform something highly predictable
> > into something unlikely to be predicted (ie: an exploit having to scan 2^31
> > possible addresses will not be really usable). It's also possible to do the
> > same with the PIT0 counter ticking at 18.2 Hz without any correlation with
> > the RTC by the way, and roughly provide 25 more bits. And if you expect
> > that the BIOS has emitted a 800 Hz beep at boot, you could still have a
> > divider of 1491 in PIT2 providing 10 more bits, though with a bit of
> > correlation with PIT0 since they use the same 1.19 MHz source. These
> > methods increase the boot time by up to one second though, but my point
> > here is that when you have nothing it's always a bit better.
>
> One other thing besides trying to extract entropy via timing would be to utilize
> more of the machine's environment in seeding the random number generator.
>
> For example on x86 the E820 table is available very early on and its addresses
> could be mixed into the random pool. An external attacker often would not know the
> precise hardware configuration.
>
> Likewise the boot parameters string could be mixed into the initial random pool as
> well - and this way distributions could create per installation seed simply by
> appending a random number to the boot string.
>
> Both methods should be very fast and robust.

Actually using RDTSC is not the worst approach. See:

https://lwn.net/images/conf/rtlws11/random-hardware.pdf

Below is a stupid implementation of that. Here are the resulting numbers
from a dozen of boot cycles:

10a3e7af4890c0ae
e7b08c8c18e6d5d9
951e12c77f79e000
ad88753ad11c9b80
db2d4dce466a3da4
b328c76d4e67368d
642edf2265e0c8a7
ef45a9f9326249d0
13e01119498797a6
0a537c8751e0349e
eb67c02dc09326dd
037d4b332020538d
793fbfda06718c69
2231535c514769e5

This mechanism could also be used to seed the random generator.

Thanks,

tglx

8<-------------------

--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1360,3 +1360,19 @@ unsigned long calibrate_delay_is_known(v
return 0;
}
#endif
+
+u64 __init tsc_early_random(void)
+{
+ u64 uninitialized_var(res);
+ int i;
+
+ if (!boot_cpu_has(X86_FEATURE_TSC))
+ return res;
+
+ res ^= rdtsc();
+ for (i = 0; i < BITS_PER_LONG; i++) {
+ res ^= ((rdtsc() & 0x04) >> 2) << i;
+ udelay(2);
+ }
+ return res;
+}
\
 
 \ /
  Last update: 2017-08-15 12:48    [W:2.060 / U:1.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site