All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomas Mraz <tmraz@redhat.com>
To: Neil Horman <nhorman@redhat.com>
Cc: Steve Grubb <sgrubb@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, "Ted Ts'o" <tytso@mit.edu>,
	Jarod Wilson <jarod@redhat.com>,
	linux-crypto@vger.kernel.org, Matt Mackall <mpm@selenic.com>,
	Herbert Xu <herbert.xu@redhat.com>,
	Stephan Mueller <stephan.mueller@atsec.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] random: add blocking facility to urandom
Date: Thu, 08 Sep 2011 08:41:57 +0200	[thread overview]
Message-ID: <1315464117.11199.51.camel@vespa.frost.loc> (raw)
In-Reply-To: <20110907235739.GA4706@hmsreliant.think-freely.org>

On Wed, 2011-09-07 at 19:57 -0400, Neil Horman wrote: 
> On Wed, Sep 07, 2011 at 04:56:49PM -0400, Steve Grubb wrote:
> > On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote:
> > > Anyway, it won't happen fast enough to actually not block.
> > > 
> > > Writing 1TB of urandom into a disk won't generate 1TB (or anything close
> > > to that) of randomness to cover for itself.
> > 
> > We don't need a 1:1 mapping of RNG used to entropy acquired. Its more on the scale of 
> > 8,000,000:1 or higher.
> > 
> Where are you getting that number from?
> 
> You may not need it, but there are other people using this facility as well that
> you're not considering.  If you assume that in the example Sasha has given, if
> conservatively, you have a modern disk with 4k sectors, and you fill each 4k
> sector with the value obtained from a 4 byte read from /dev/urandom, You will:
> 
> 1) Generate an interrupt for every page you write, which in turn will add at
> most 12 bits to the entropy pool
> 
> 2) Extract 32 bits from the entropy pool
> 
> Thats just a loosing proposition.   Barring further entropy generation from
> another source, this is bound to stall with this feature enabled. 
Why so? In the case the blocking limit is on 8MBits of data read
from /dev/urandom per every 1 bit added to the entropy pool (this is not
the exact way how the patch behaves but we can approximate that) I do
not see the /dev/urandom can block if the bytes read from it are written
to disk device - of course only if the device adds entropy into the
primary pool when there are writes on the device.

Of course you can still easily make the /dev/urandom to occasionally
block with this patch, just read the data and drop it.

But you have to understand that the value that will be set with the
sysctl added by this patch will be large in the order of millions of
bits.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

  reply	other threads:[~2011-09-08  6:42 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-02 14:37 [PATCH] random: add blocking facility to urandom Jarod Wilson
2011-09-05  2:36 ` Sandy Harris
2011-09-06 14:09   ` Stephan Mueller
2011-09-07 17:38 ` Jarod Wilson
2011-09-07 18:12   ` Sasha Levin
2011-09-07 18:26     ` Jarod Wilson
2011-09-07 19:05       ` Sasha Levin
2011-09-07 19:30         ` Jarod Wilson
2011-09-07 20:00           ` Sasha Levin
2011-09-07 19:35         ` Neil Horman
2011-09-07 19:27       ` Ted Ts'o
2011-09-07 19:36         ` Jarod Wilson
2011-09-07 19:36           ` Jarod Wilson
2011-09-08  2:43           ` Sandy Harris
2011-09-07 19:49         ` David Miller
2011-09-07 20:02         ` Steve Grubb
2011-09-07 20:23           ` Sasha Levin
2011-09-07 20:30             ` Steve Grubb
2011-09-07 20:37               ` Sasha Levin
2011-09-07 20:56                 ` Steve Grubb
2011-09-07 21:10                   ` Sasha Levin
2011-09-07 21:28                     ` Steve Grubb
2011-09-07 21:38                       ` Sasha Levin
2011-09-07 21:35                     ` Jarod Wilson
2011-09-07 21:43                       ` Steve Grubb
2011-09-07 22:46                         ` Sven-Haegar Koch
2011-09-08  7:21                         ` Sasha Levin
2011-09-07 23:57                   ` Neil Horman
2011-09-08  6:41                     ` Tomas Mraz [this message]
2011-09-08 12:52                       ` Neil Horman
2011-09-08 13:11                         ` Steve Grubb
2011-09-08 13:49                           ` Neil Horman
2011-09-09  2:21                           ` Sandy Harris
2011-09-09 13:04                             ` Steve Grubb
2011-09-09 16:25                               ` Ted Ts'o
2011-09-09 21:27                               ` Thomas Gleixner
2011-09-12 13:56                                 ` Jarod Wilson
2011-09-13 10:58                                   ` Peter Zijlstra
2011-09-13 12:18                                     ` Jarod Wilson
2011-09-11  2:05                             ` Valdis.Kletnieks
2011-09-12 13:55                               ` Jarod Wilson
2011-09-12 16:58                                 ` Valdis.Kletnieks
2011-09-12 18:26                                   ` Jarod Wilson
2011-09-07 20:33           ` Neil Horman
2011-09-07 20:48             ` Steve Grubb
2011-09-07 21:18           ` Ted Ts'o
2011-09-07 21:27             ` Stephan Mueller
2011-09-07 21:27               ` Stephan Mueller
2011-09-07 21:38               ` Ted Ts'o
2011-09-08  8:44               ` Christoph Hellwig
2011-09-08 11:48                 ` Steve Grubb
2011-09-08 16:13                   ` David Miller
2011-09-09 19:08                     ` Eric Paris
2011-09-09 19:12                       ` Neil Horman
2011-09-08  8:42             ` Christoph Hellwig
2011-09-08  8:42               ` Christoph Hellwig
2011-09-07 21:20           ` Nikos Mavrogiannopoulos
2011-09-08  8:41           ` Christoph Hellwig
2011-09-12 14:02         ` Jarod Wilson
2011-09-12 14:02           ` Jarod Wilson
2011-09-12 14:58           ` Neil Horman
2011-09-12 17:06           ` Mark Brown

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=1315464117.11199.51.camel@vespa.frost.loc \
    --to=tmraz@redhat.com \
    --cc=herbert.xu@redhat.com \
    --cc=jarod@redhat.com \
    --cc=levinsasha928@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=nhorman@redhat.com \
    --cc=sgrubb@redhat.com \
    --cc=stephan.mueller@atsec.com \
    --cc=tytso@mit.edu \
    /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.