[PATCH] Require minimum random data entropy when creating LUKS (#1073679)

Vratislav Podzimek vpodzime at redhat.com
Wed Sep 3 13:14:02 UTC 2014


On Tue, 2014-09-02 at 18:07 -0700, Brian C. Lane wrote:
> On Mon, Sep 01, 2014 at 09:45:56AM +0200, Vratislav Podzimek wrote:
> > 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.
> 
> Yeah, I just saw that.
> 
> > 
> > [1] http://vpodzime.fedorapeople.org/installations_entropy_report.pdf
> 
> Thanks! I remember looking at that before, but didn't have it
> bookmarked.
> 
> > 
> > > 
> > > 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
> > > up.
> > 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.
> 
> If that works I think it would be the right way to go, you are then
> guaranteed to either take forever or get enough entropy and guiding the
> user to do something will help make sure it finishes faster.
Agreed. However, the problem is that python bindings for cryptsetup
doesn't export the random data source selection. We could file and RFE
to add it, but I'm not sure it's worth it. For Fedora 22+ we are going
to use libblockdev which uses the C API and can select the random data
source.

Or we could switch to using the cryptsetup binary, what would be quite a
big change which, again, I'm not sure is worth it. The other option is
to leave the potential race condition as it is and fix it if somebody
actually asks us to do so.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list