linux-kernel - Re: [PATCH 00/11] random: code cleanups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131113033205.GA9214@thunk.org>
Date:	Tue, 12 Nov 2013 22:32:05 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Greg Price <price@....EDU>
Cc:	linux-kernel@...r.kernel.org, Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 00/11] random: code cleanups

On Tue, Nov 12, 2013 at 05:40:09PM -0500, Greg Price wrote:
> 
> Beyond these easy cleanups, I have a couple of patches queued up (just
> written yesterday, not quite finished) to make /dev/urandom block at
> boot until it has enough entropy, as the "Mining your P's and Q's"
> paper recommended and people have occasionally discussed since then.
> Those patches were definitely for after 3.13 anyway, and I'll send
> them when they're ready.  I see some notifications and warnings in
> this direction in the random.git tree, which is great.

One of the things I've been thinking about with respect to making
/dev/urandom block is being able to configure (via a module parameter
which could be specified on the boot command line) which allows us to
set a limit for how long /dev/urandom will block after which we log a
high priority message that there was an attempt to read from
/dev/urandom which couldn't be satisified, and then allowing the
/dev/urandom read to succed.

The basic idea is that we don't want to break systems, but we do want
to gently coerce people to do the right thing.  Otherwise, I'm worried
that distros, or embedded/mobile/consume electronics engineers would
just patch out the check.  If we make the default be something like
"block for 5 minutes", and then log a message, we won't completely
break a user who is trying to login to a VM, but it will be obvious,
both from the delay and from the kern.crit log message, that there is
a potential problem here that a system administrator needs to worry
about.

						- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/