From: Steve Grubb <sgrubb@redhat.com>
To: Neil Horman <nhorman@redhat.com>
Cc: Tomas Mraz <tmraz@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, 8 Sep 2011 09:11:12 -0400 [thread overview]
Message-ID: <201109080911.12921.sgrubb@redhat.com> (raw)
In-Reply-To: <20110908125234.GD13657@hmsreliant.think-freely.org>
On Thursday, September 08, 2011 08:52:34 AM Neil Horman wrote:
> > to disk device - of course only if the device adds entropy into the
> > primary pool when there are writes on the device.
>
> Yes, and thats a problem. We're assuming in the above case that writes to
> disk generate interrupts which in turn generate entropy in the pool. If
> that happens, then yes, it can be difficult (though far from impossible)
> to block on urandom with this patch and a sufficiently high blocking
> threshold. But interrupt randomness is only added for interrupts flagged
> with
> IRQF_SAMPLE_RANDOM, and if you look, almost no hard irqs add that flag. So
> its possible (and even likely) that writing to disk will not generate
> additional entropy.
The system being low on entropy is another problem that should be addressed. For our
purposes, we cannot say take it from TPM or RDRND or any plugin board. We have to have
the mathematical analysis that goes with it, we need to know where the entropy comes
from, and a worst case entropy estimation. It has to be documented in detail. The only
way we can be certain is if its based on system events. Linux systems are constantly
low on entropy and this really needs addressing. But that is a separate issue. For
real world use, I'd recommend everyone use a TPM chip + rngd and you'll never be short
on random numbers. But in the case where we are certifying the OS, we need the
mathematical argument to prove that unaided, things are correct.
> > 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.
>
> You can guarantee that?
One proposal I made to Jarod was to add some minimum threshold that would prevent
people from setting a value of 2, for example. Maybe the threshold could be set at 64K
or higher depending on what number we get back from BSI.
> This sysctl allows for a setting of 2 just as easily as it allows for a setting of
> 8,000,000. And the former is sure to break or otherwise adversely affect
> applications that expect urandom to never block. Thats what Sasha was referring to,
> saying that patch makes it easy for admins to make serious mistakes.
Would a sufficiently high threshold make this easier to accept?
-Steve
next prev parent reply other threads:[~2011-09-08 13:11 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
2011-09-08 12:52 ` Neil Horman
2011-09-08 13:11 ` Steve Grubb [this message]
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=201109080911.12921.sgrubb@redhat.com \
--to=sgrubb@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=stephan.mueller@atsec.com \
--cc=tmraz@redhat.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.