[blivet] Allow the wait_for_entropy callback enforce continue

Anne Mulhern amulhern at redhat.com
Mon Nov 3 14:53:55 UTC 2014





----- Original Message -----
> From: "Vratislav Podzimek" <vpodzime at redhat.com>
> To: anaconda-patches at lists.fedorahosted.org
> Sent: Monday, November 3, 2014 7:09:51 AM
> Subject: [blivet] Allow the wait_for_entropy callback enforce continue
> 
> This way e.g a timeout or a way allowing user to ignore the lack of entropy
> can
> be implemented.
> 
> Related: rhbz#1073679
> Signed-off-by: Vratislav Podzimek <vpodzime at redhat.com>
> ---
>  blivet/deviceaction.py | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/blivet/deviceaction.py b/blivet/deviceaction.py
> index 1679718..0aee993 100644
> --- a/blivet/deviceaction.py
> +++ b/blivet/deviceaction.py
> @@ -551,13 +551,22 @@ class ActionCreateFormat(DeviceAction):
>              min_required_entropy = self.device.format.min_luks_entropy
>              current_entropy = get_current_entropy()
>              if current_entropy < min_required_entropy:
> +                force_cont = False
>                  if callbacks and callbacks.wait_for_entropy:
>                      msg = _("Not enough entropy to create LUKS format. "
>                              "%d bits are needed.") % min_required_entropy
> -                    callbacks.wait_for_entropy(msg, min_required_entropy)
> +                    force_cont = callbacks.wait_for_entropy(msg,
> min_required_entropy)
> +
> +                if force_cont:
> +                    # log warning and set format's required entropy to 0
> +                    log.warning("Forcing LUKS creation regardless of enough
> "
> +                                "random data entropy (%d/%d)",

Line above would be better as

"Forcing LUKS creation regardless of insufficient available entropy."

> +                                get_current_entropy(), min_required_entropy)
> +                    self.device.format.min_luks_entropy = 0
>  
>          self.device.format.create(device=self.device.path,
>                                    options=self.device.formatArgs)
> +
>          # Get the UUID now that the format is created
>          udev.settle()
>          self.device.updateSysfsPath()
> --
> 1.9.3
> 
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> 

I feel like there's a bit of a design issue here.

It seems like if you can't get the entropy, and set min_luks_entropy to 0,
then crypto.luks_format() can never hang, so that is good.

But if you have enough entropy here, but it drops by the time crypto.luks_format()
gets called, then crypto.luks_format() can still hang forever.
Since devicelibs is envisioned as being a distinct library crypto.luks_format() could be
called without any check for sufficient entropy by the calling code, as well.

I think that crypto.luks_format() should do one of:
a) have a time out itself
b) document, in the method header, that the method can hang forever waiting for minimum entropy
to be reached (especially as no effort is made to increase min entropy within the method)
c) not wait for minimum entropy to be reached (assume that calling code has handled that problem)

- mulhern 




More information about the anaconda-patches mailing list