On Mon, 2014-11-03 at 09:53 -0500, Anne Mulhern wrote:
----- Original Message -----
> From: "Vratislav Podzimek" <vpodzime(a)redhat.com>
> To: anaconda-patches(a)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(a)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(a)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.
We've already
discussed that. There's no any atomicity and lock for the
random data pool, so we could only push the timeout/hang further in the
stack, pushing it all the way the kernel in the end -- with interactive
timeout???
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.
That's why it has a min_entropy parameter (defaulting to 0) and nothing
hardcoded.
I think that crypto.luks_format() should do one of:
a) have a time out itself
How would you let user now what happens/happened?
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)
Is there any effort that could be made to increase entropy? I don't
think so. I can document the behaviour, but I think it is quite obvious.
c) not wait for minimum entropy to be reached (assume that calling
code has handled that problem)
Not a good idea because there might be the drop you
mentioned and we
should check entropy as late as possible. There's really small chance
that there would be some significant drop while those ~10 lines of
Python code are executed.
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic