On Wed, 2011-09-07 at 16:56 -0400, Steve Grubb wrote:On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote:On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote:I think they draw from the same pool.On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote:I thought you need to feed random, not urandom.On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote:Which should generate disk activity and feed entropy to urandom.On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote:As far as I remember, several wipe utilities are using /dev/urandom toOn Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote:The only time this kicks in is when a system is under attack. If youWe're looking for a generic solution here that doesn't requireYeah, but there are userspace programs that depend on urandom not
re-educating every single piece of userspace. And anything done
in userspace is going to be full of possible holes -- there
needs to be something in place that actually *enforces* the
policy, and centralized accounting/tracking, lest you wind up
with multiple processes racing to grab the entropy.
blocking... so your proposed change would break them.
have set this and the system is running as normal, you will never
notice it even there. Almost all uses of urandom grab 4 bytes and
seed openssl or libgcrypt or nss. It then uses those libraries.
There are the odd cases where something uses urandom to generate a
key or otherwise grab a chunk of bytes, but these are still small
reads in the scheme of things. Can you think of any legitimate use
of urandom that grabs 100K or 1M from urandom? Even those numbers
still won't hit the sysctl on a normally function system.
overwrite disks (possibly several times).
There is a blocking and a non blocking pool.
Anyway, it won't happen fast enough to actually not block.We don't need a 1:1 mapping of RNG used to entropy acquired. Its more on the scale of
Writing 1TB of urandom into a disk won't generate 1TB (or anything close
to that) of randomness to cover for itself.
8,000,000:1 or higher.
I'm just saying that writing 1TB into a disk using urandom will start to
block, it won't generate enough randomness by itself.
Why not implement it as a user mode CUSE driver that would
wrap /dev/urandom and make it behave any way you want to? why push it
into the kernel?