All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Borg <kentborg@borg.org>
To: Venkatesh Pallipadi <venki@google.com>
Cc: Jarod Wilson <jarod@redhat.com>,
	linux-crypto@vger.kernel.org, Matt Mackall <mpm@selenic.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	John Stultz <johnstul@us.ibm.com>,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	"David S. Miller" <davem@davemloft.net>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: [PATCH 4/5] tsc: wire up entropy generation function
Date: Mon, 13 Jun 2011 19:55:28 -0400	[thread overview]
Message-ID: <4DF6A370.3000200@borg.org> (raw)
In-Reply-To: <BANLkTin=BkfyPjaWRc1rfTWU34NLdn7FLgY6yUbSrjzPpx7Gmg@mail.gmail.com>

Venkatesh Pallipadi wrote:
> On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson <jarod@redhat.com> wrote:
>   
>> TSC is high enough resolution that we can use its low-order byte to
>> stir new data into the random number generator entropy pool.
>
> From what I vaguely remember from years past, rdtsc, especially last
> few bits of it are not very good as random number source. 

It doesn't have to be "random" (a very high bar), it just has to be 
somewhat non-deterministic to contain entropy (a low-bar).  The idea 
isn't to  use the TSC as a random number, only to use it for mixing the 
pool.  If somehow the TSC were *completely* deterministic, we would only 
fail to add entropy, any entropy already in the pool would still be just 
as good as before, no harm done.  (Like a perfect shuffle of an already 
randomly arranged deck of cards.)

Okay, not "no harm", a ~little~ harm.  There are two problems with using 
the TSC if it doesn't have much entropy:

  1. It wastes computrons.  Okay, have efficient code, don't run it too 
often.

  2. Entropy estimates might be too high.  Okay, but entropy estimation 
is a horrible
     problem in the best of well-defined circumstances.  Some (Schneier 
I think) say
     it isn't worth attempting.  Difficulty in estimating entropy is a 
bad excuse for
     starving the system of entropy.  Better to credit no entropy than 
to collect
     no entropy.  In a server, entropy sources should not be discarded.

> As they are
> based on lower bus frequency and a multiplier. 

Based on a lower bus frequency, but multiplied up in the CPU.  Why?  
Because synchronous clock distribution is very difficult at GHz speeds.  
Heck, even inside the CPU, clock distribution is not a trivial matter.  
It is impossible for anyone at a distance to know the LSB of the TSC at 
any given moment because the very concept of a "given moment" is ill 
defined at any distance.

And how is the low-frequency clock multiplied up?  With analog circuitry 
(a PLL, right?), and analog is a source of indeterminism.  There is 
going to be a little jitter in there.  Differences from chip-to-chip, 
with slight power supply changes, with temperature, with time.


Disclaimer: I have not looked at the patch carefully, it might be shit.  
But the idea of letting us add some entropy is excellent!


-kb, the Kent who has been paid money for building a defensible RNG.

  parent reply	other threads:[~2011-06-13 23:55 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-13 22:06 [PATCH 0/5] Feed entropy pool via high-resolution clocksources Jarod Wilson
2011-06-13 22:06 ` [PATCH 1/5] random: add new clocksource entropy interface Jarod Wilson
2011-06-13 22:06 ` [PATCH 2/5] clocksource: add support for entropy-generation function Jarod Wilson
2011-06-17 20:52   ` Thomas Gleixner
2011-06-17 21:19     ` Jarod Wilson
2011-06-13 22:06 ` [PATCH 3/5] hpet: wire up entropy generation function Jarod Wilson
2011-06-13 22:06 ` [PATCH 4/5] tsc: " Jarod Wilson
2011-06-13 22:27   ` Venkatesh Pallipadi
2011-06-13 22:35     ` Jarod Wilson
2011-06-13 22:36     ` H. Peter Anvin
2011-06-13 23:10       ` Matt Mackall
2011-06-14 18:11         ` H. Peter Anvin
2011-06-14  0:39       ` Kent Borg
2011-06-14  1:47         ` H. Peter Anvin
2011-06-14 12:39           ` Kent Borg
2011-06-14 14:33             ` Matt Mackall
2011-06-14 17:48               ` Kent Borg
2011-06-14 18:00                 ` Matt Mackall
2011-06-14 20:04                   ` Kent Borg
2011-06-14 21:04                     ` Matt Mackall
2011-06-14 14:02           ` Jarod Wilson
2011-06-13 23:55     ` Kent Borg [this message]
2011-06-17 20:58     ` Thomas Gleixner
2011-06-13 22:06 ` [PATCH 5/5] misc: add clocksource-based entropy generation driver Jarod Wilson
2011-06-17 21:01   ` Thomas Gleixner
2011-06-13 22:38 ` [PATCH 0/5] Feed entropy pool via high-resolution clocksources john stultz
2011-06-14 14:25   ` Jarod Wilson
2011-06-13 23:15 ` Matt Mackall
2011-06-14 15:18   ` Jarod Wilson
2011-06-14 15:22     ` Jarod Wilson
2011-06-14 17:13     ` Matt Mackall
2011-06-14 20:17       ` Jarod Wilson
2011-06-14 21:45         ` Matt Mackall
2011-06-14 22:51           ` Jarod Wilson
2011-06-14 23:12             ` Matt Mackall
2011-06-15 14:49               ` Jarod Wilson
2011-06-15 20:06                 ` Matt Mackall
2011-06-17 18:51                   ` Jarod Wilson
2011-06-17 19:29                     ` Neil Horman
2011-06-17 20:46                       ` Matt Mackall
2011-06-17 19:48               ` hpas
2011-06-17 20:28                 ` Matt Mackall
2011-06-18 22:40                   ` H. Peter Anvin
2011-06-19 13:38                     ` Neil Horman
2011-06-19 15:07                       ` Herbert Xu
2011-06-20  0:01                         ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF6A370.3000200@borg.org \
    --to=kentborg@borg.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.hengli.com.au \
    --cc=hpa@zytor.com \
    --cc=jarod@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mpm@selenic.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venki@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.