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

Brian C. Lane bcl at redhat.com
Wed Sep 3 01:07:19 UTC 2014


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.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


More information about the anaconda-patches mailing list