Re: [PATCH 3/3] Wait for enough entropy when creating LUKS format

[Vratislav Podzimek]

On Tue, 2013-05-28 at 11:00 -0400, Chris Lumens wrote:
> > @@ -462,6 +466,19 @@ class ActionCreateFormat(DeviceAction):
> >          self.device.disk.format.commitToDisk()
> >
> >    if isinstance(self.device.format, luks.LUKS):
> >        # LUKS needs to wait for random data entropy if it is too low
> >        current_entropy = get_current_entropy()
> >        if current_entropy < luks.MINIMAL_ENTROPY:
> >            if callbacks and "WaitForEntropy" in callbacks:
> >                msg = "Not enough entropy to create LUKS format. "\
> >                      "%d bits are needed." % luks.MINIMAL_ENTROPY
> >                callbacks["WaitForEntropy"](msg, luks.MINIMAL_ENTROPY)
> >            while get_current_entropy() < luks.MINIMAL_ENTROPY:
> >                # wait for entropy to become high enough
> >                time.sleep(1)
> >    self.device.format.create(device=self.device.path,
> >                              options=self.device.formatArgs)
> >    # Get the UUID now that the format is created
>
> Would it also be possible to somehow unpredictably stir things up here
> to increase available entropy?  That could help the loop take less time
> to complete.

I was thinking about leaving that to the callback (as the Anaconda's one
do), but maybe there could be done something even in the loop. However,
it's quite hard to come up with something "unpredictable". If we had
anything like that we could directly populate the kernel's pool. The
only thing that comes to my mind is some "quite random" reading from
disks, that would generate entropy through seek times and so on, but I'm
not sure anything like would be possible.

But the most important thing is that the entropy of e.g. 256 bits (I'm
still waiting for the right value of the threshold) should be already
available or gathered quite quickly.