Re: early x86 unseeded randomness

On Wed, Aug 16, 2017 at 11:13:03AM +0200, Thomas Gleixner wrote: > On Tue, 15 Aug 2017, Theodore Ts'o wrote: > > If we really want to do this, I'd much rather *not* have code calling > > tsc_early_random(). We're better off having the code call > > get_random_bytes() and/or get_random_u32(), and

Re: early x86 unseeded randomness

On Wed, Aug 16, 2017 at 11:13:03AM +0200, Thomas Gleixner wrote: > On Tue, 15 Aug 2017, Theodore Ts'o wrote: > > If we really want to do this, I'd much rather *not* have code calling > > tsc_early_random(). We're better off having the code call > > get_random_bytes() and/or get_random_u32(), and

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Theodore Ts'o wrote: > If we really want to do this, I'd much rather *not* have code calling > tsc_early_random(). We're better off having the code call > get_random_bytes() and/or get_random_u32(), and having these systems > use RDRAND if available, and if not, falling back

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Theodore Ts'o wrote: > If we really want to do this, I'd much rather *not* have code calling > tsc_early_random(). We're better off having the code call > get_random_bytes() and/or get_random_u32(), and having these systems > use RDRAND if available, and if not, falling back

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 07:37:05PM +0200, Thomas Gleixner wrote: > That exploits the fact that the CPU and caches run at a different non > synchronized clock than the memory controller and therefore the execution > time for both the wbinvd() and the memchr_inv() measured in TSC cycles is > non

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 07:37:05PM +0200, Thomas Gleixner wrote: > That exploits the fact that the CPU and caches run at a different non > synchronized clock than the memory controller and therefore the execution > time for both the wbinvd() and the memchr_inv() measured in TSC cycles is > non

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 04:42:47PM +0200, Thomas Gleixner wrote: > Care to read the paper? > > We tried that 6 years ago on a wide range of machines from server to stupid > first generation in order ATOM chips. All of them exposed more or less the > same behaviour and passed RND validation tests.

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 04:42:47PM +0200, Thomas Gleixner wrote: > Care to read the paper? > > We tried that 6 years ago on a wide range of machines from server to stupid > first generation in order ATOM chips. All of them exposed more or less the > same behaviour and passed RND validation tests.

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Thomas Gleixner wrote: > On Tue, 15 Aug 2017, Theodore Ts'o wrote: > > On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > > > > > +u64 __init tsc_early_random(void) > > > > > +{ > > > > > + u64 uninitialized_var(res); > > > > > + int i; > > > > > + > >

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Thomas Gleixner wrote: > On Tue, 15 Aug 2017, Theodore Ts'o wrote: > > On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > > > > > +u64 __init tsc_early_random(void) > > > > > +{ > > > > > + u64 uninitialized_var(res); > > > > > + int i; > > > > > + > >

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 04:42:47PM +0200, Thomas Gleixner wrote: > I'm not saying it's a replacement for the run time random generator, but > it's exceptionally good and reasonably fast for the early boot > randomization. ... which suffices our purposes. It's not like we're going to generate

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 04:42:47PM +0200, Thomas Gleixner wrote: > I'm not saying it's a replacement for the run time random generator, but > it's exceptionally good and reasonably fast for the early boot > randomization. ... which suffices our purposes. It's not like we're going to generate

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > Go ahead. What you actually want to do is to replace boot_cpu_has() with a > real cpuid() check because boot_cpu_has() is not initialized on real early > boot. Right. -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > Go ahead. What you actually want to do is to replace boot_cpu_has() with a > real cpuid() check because boot_cpu_has() is not initialized on real early > boot. Right. -- Regards/Gruss, Boris. Good mailing practices for 400:

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Theodore Ts'o wrote: > On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > > > > +u64 __init tsc_early_random(void) > > > > +{ > > > > + u64 uninitialized_var(res); > > > > + int i; > > > > + > > > > + if (!boot_cpu_has(X86_FEATURE_TSC)) > > >

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Theodore Ts'o wrote: > On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > > > > +u64 __init tsc_early_random(void) > > > > +{ > > > > + u64 uninitialized_var(res); > > > > + int i; > > > > + > > > > + if (!boot_cpu_has(X86_FEATURE_TSC)) > > >

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > > > +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;

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote: > > > +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;

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Borislav Petkov wrote: > On Tue, Aug 15, 2017 at 12:47:36PM +0200, Thomas Gleixner wrote: > > 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; > > }

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Borislav Petkov wrote: > On Tue, Aug 15, 2017 at 12:47:36PM +0200, Thomas Gleixner wrote: > > 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; > > }

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 12:47:36PM +0200, Thomas Gleixner wrote: > 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) > +{ >

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 12:47:36PM +0200, Thomas Gleixner wrote: > 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) > +{ >

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 08:09:50AM -0400, Theodore Ts'o wrote: > On Tue, Aug 15, 2017 at 10:05:46AM +0200, Ingo Molnar wrote: > > > > * Willy Tarreau wrote: > > > > > > > > > > Nowadays we could use similar methods using RDTSC providing more > > > > > accurate > > > > > counting.

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 08:09:50AM -0400, Theodore Ts'o wrote: > On Tue, Aug 15, 2017 at 10:05:46AM +0200, Ingo Molnar wrote: > > > > * Willy Tarreau wrote: > > > > > > > > > > Nowadays we could use similar methods using RDTSC providing more > > > > > accurate > > > > > counting. This doesn't

Re: early x86 unseeded randomness

Ingo Molnar writes: > * Willy Tarreau 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

Re: early x86 unseeded randomness

Ingo Molnar writes: > * Willy Tarreau 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

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 10:05:46AM +0200, Ingo Molnar wrote: > > > * Willy Tarreau 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

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 10:05:46AM +0200, Ingo Molnar wrote: > > > * Willy Tarreau 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

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Ingo Molnar wrote: > * Willy Tarreau 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

Re: early x86 unseeded randomness

On Tue, 15 Aug 2017, Ingo Molnar wrote: > * Willy Tarreau 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

Re: early x86 unseeded randomness

* Willy Tarreau wrote: > On Tue, Aug 15, 2017 at 09:42:54AM +0200, Ingo Molnar wrote: > > > > * Willy Tarreau wrote: > > > > > Nowadays we could use similar methods using RDTSC providing more accurate > > > counting. This doesn't provide a lot of entropy of course,

Re: early x86 unseeded randomness

* Willy Tarreau wrote: > On Tue, Aug 15, 2017 at 09:42:54AM +0200, Ingo Molnar wrote: > > > > * Willy Tarreau 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

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 09:42:54AM +0200, Ingo Molnar wrote: > > * Willy Tarreau 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

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 09:42:54AM +0200, Ingo Molnar wrote: > > * Willy Tarreau 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.

Re: early x86 unseeded randomness

* Willy Tarreau 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

Re: early x86 unseeded randomness

* Willy Tarreau 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

Re: early x86 unseeded randomness

Hi Ted, On Mon, Aug 14, 2017 at 09:31:24PM -0400, Theodore Ts'o wrote: > The real fix is to do what OpenBSD does, which is to teach the > bootloader (e.g., grub) to read from some file such as > /var/lib/urandom/random-seed, and then to have the init scripts > overwrite it with a new set of

Re: early x86 unseeded randomness

Hi Ted, On Mon, Aug 14, 2017 at 09:31:24PM -0400, Theodore Ts'o wrote: > The real fix is to do what OpenBSD does, which is to teach the > bootloader (e.g., grub) to read from some file such as > /var/lib/urandom/random-seed, and then to have the init scripts > overwrite it with a new set of

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 09:00:13PM +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 11:17:37AM -0700, Linus Torvalds wrote: > > Ok, guys, you ALL need to learn that blindly just trying to get rid of > > warnings IS A HORRIBLE IDEA. > > Not blindly - I was actually suggesting/asking whether

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 09:00:13PM +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 11:17:37AM -0700, Linus Torvalds wrote: > > Ok, guys, you ALL need to learn that blindly just trying to get rid of > > warnings IS A HORRIBLE IDEA. > > Not blindly - I was actually suggesting/asking whether

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 11:17:37AM -0700, Linus Torvalds wrote: > Ok, guys, you ALL need to learn that blindly just trying to get rid of > warnings IS A HORRIBLE IDEA. Not blindly - I was actually suggesting/asking whether falling back to the TSC that early during boot might make more sense than

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 11:17:37AM -0700, Linus Torvalds wrote: > Ok, guys, you ALL need to learn that blindly just trying to get rid of > warnings IS A HORRIBLE IDEA. Not blindly - I was actually suggesting/asking whether falling back to the TSC that early during boot might make more sense than

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 11:00 AM, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 10:47:47AM -0700, Linus Torvalds wrote: >> Plus on modern x86, you'll always get at least the hardware >> randomness, which is fundamentally much better anyway. > > Right, my only intention was to

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 11:00 AM, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 10:47:47AM -0700, Linus Torvalds wrote: >> Plus on modern x86, you'll always get at least the hardware >> randomness, which is fundamentally much better anyway. > > Right, my only intention was to get rid of those:

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 10:47:47AM -0700, Linus Torvalds wrote: > Plus on modern x86, you'll always get at least the hardware > randomness, which is fundamentally much better anyway. Right, my only intention was to get rid of those: [0.00] random: get_random_bytes called from

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 10:47:47AM -0700, Linus Torvalds wrote: > Plus on modern x86, you'll always get at least the hardware > randomness, which is fundamentally much better anyway. Right, my only intention was to get rid of those: [0.00] random: get_random_bytes called from

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 10:35 AM, Borislav Petkov wrote: > > how about we address that unseeded randomness usage during early boot by > falling back on the TSC on x86? I mean, we already do that for the stack > canary value anyway... That patch is completely broken: > +

Re: early x86 unseeded randomness

On Mon, Aug 14, 2017 at 10:35 AM, Borislav Petkov wrote: > > how about we address that unseeded randomness usage during early boot by > falling back on the TSC on x86? I mean, we already do that for the stack > canary value anyway... That patch is completely broken: > + if (crng_ready())