linux-kernel - Re: [PATCH] random: Add "initialized" variable to proc

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: <535FE68C.8060002@redhat.com>
Date:	Tue, 29 Apr 2014 19:51:08 +0200
From:	Florian Weimer <fweimer@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] random: Add "initialized" variable to proc

On 04/28/2014 11:41 PM, Theodore Ts'o wrote:
> On Mon, Apr 28, 2014 at 09:52:11PM +0200, Florian Weimer wrote:
>> Before this change, you had to check kernel log messages to see if the
>> non-blocking pool had been properly initialized.  With this change, you
>> can consult the file /proc/sys/kernel/random/intialized instead.
>>
>> Signed-off-by: Florian Weimer <fweimer@...hat.com>
>
> The main reason why I hadn't added a facility like this was because
> the main goal was to make knowledge of when the /dev/urandom entropy
> pool had been fully initialized could be made clear.  In fact, at
> least on my laptop, this happened at 2.5 seconds after boot, which is
> after the hard drives had been probed, and before all of the various
> laptop devices have been fully probed.

I've got a (physical) machine where it happens after ten seconds, or 
much longer if there is no activity.

I've seen cases where on the first boot of virtual machines, the SSH key 
was generated before the printk with the initialization message.  It's 
not a problem if you install the OS first and then generate the keys, 
but for booting from pre-provisioned images, it could be.  (I have no 
evidence that this hurts the quality of the generated key material, this 
is just based on what's reported by the kernel.)

> My goal was to see if we could make it be more or less guaranteed that
> by the time userspace daemons started coming up, in practice
> /dev/urandom would be initialized, so we wouldn't have to change
> userspace.  And for the most part, this isn't a problem.

I'm not sure if I want to bet an increasingly crucial part of the boot 
design on the continuing availability of the current entropy levels 
(which could go down as the result of environmental changes or a 
reassessment of the entropy that actually comes into the system).

> Now there may be systems where the device probe can happen much more
> quickly. in which case it does make sense for really paranoid crypto
> libraries to check if the urandom pool has been fully initialized.
> But in that case, instead of (or perhaps in addition to) providing a
> file which a library daemon could poll on, to provide an ioctl
> interface which allows userspace to block until /dev/urandom has been
> initialized.

Or a new /dev/?random device that blocks until initialized, but behaves 
just like /dev/urandom after that.   The question is how useful it would 
be because of the deadlock scenario.

-- 
Florian Weimer / Red Hat Product Security Team
--
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/