[PATCH] Require minimum random data entropy when creating LUKS (#1073679)
vpodzime at redhat.com
Mon Sep 1 07:45:56 UTC 2014
On Fri, 2014-08-29 at 17:24 -0700, Brian C. Lane wrote:
> On Fri, Aug 29, 2014 at 02:20:03PM +0200, Vratislav Podzimek wrote:
> > Creating new LUKS format requires high-quality random data and such quality may
> > be specified by minimum entropy of kernel's random data pool required. We can
> > tell blivet what should be the minimum entropy available when creating LUKS and
> > we can provide callbacks which inform users about what's happening and how they
> > can help to increase the available entropy.
> Some somewhat random (bad pun) thoughts:
A general answer first -- please see my reply to clumens' comment
describing how current situation looks like with the sane entropy levels
required and available entropy in typical installations.
> Normal users aren't going to have the slightest idea what this means, we
> should do as much as we can to hide it from them. Before showing the
> dialog set a timer of, say, 15 seconds and then if there isn't enough
> show it.
Trying to wait first for let's say 15 seconds sounds like a good idea to
me. And we can use the progress reporting mechanism to inform user
what's going on after let's say first 5-10 seconds of "inactivity".
> Are we sure this is the right way to proceed? I'd expect LUKS to make
> sure it has sufficient entropy, but I haven't looked at its code. Ok, I
> read the manpage and it suggests using /dev/random if running out of
> entropy is an issue.
LUKS basically cannot do anything better than we do. Waiting for enough
entropy may take quite some time and without user's interaction it may
actually never end. If you read the manpage a bit further you'd also see
"""Using /dev/random can block a long time, potentially forever, if not
enough entropy can be harvested by the kernel."""
I don't know how much random data luksFormat requires, but /dev/random
is terribly slow.
> When I was thinking about adding rngd to the install I came across an
> analysis of the entropy pool on VMs, and IIRC the conclusion was that
> the kernel pretty much does the right thing and extra help wasn't
> needed. Of course I can't find the paper now.
You can have a look at my paper  I wrote as a part of the school
project. You're right the situation is not that bad. As I've mentioned
in the reply to clumens' comments with a sane value of minimum required
entropy like 256 bits, the wait will hardly ever happen. A bit
problematic are kickstart installations where everything happens quite
fast and we create LUKS format soon after the system boots and after
running several binaries which consumes entropy from the pool.
> There is also a chance that these checks and enforcement don't help, eg.
> something drains the pool at the same time LUKS needs it, but after
> we've checked for it. Instead of waiting for enough entropy maybe it
> should switch LUKS to using /dev/random so it blocks until enough shows
AFAICT there's no lock for /dev/urandom so this race condition cannot be
fixed neither in cryptsetup nor anywhere else. We could switch LUKS to
using /dev/random, but that would probably still require us to check the
available entropy and guide user through its generation so
that /dev/random gets enough entropy to provide enough data to
cryptsetup. I'll test that to see how it behaves.
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
More information about the anaconda-patches