all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Marius Bakke <mbakke@fastmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 37501@debbugs.gnu.org
Subject: bug#37501: [core-updates] Entropy starvation during boot
Date: Sat, 05 Oct 2019 14:56:49 +0200	[thread overview]
Message-ID: <87pnjb73la.fsf@devup.no> (raw)
In-Reply-To: <87y2y0x453.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> I read some of these, and our ‘urandom-seed-service-type’ has the same
>> bug as <https://github.com/systemd/systemd/issues/4271>.  Namely, we
>> write the previous seed to /dev/urandom but we don’t credit the
>> entropy.
>
> Now that I think about it, ‘urandom-seed’ normally contributes 512 bytes
> of entropy, but immediately after it *consumes* 512 bytes of entropy:
>
>           ;; Immediately refresh the seed in case the system doesn't
>           ;; shut down cleanly.
>           (call-with-input-file "/dev/urandom"
>             (lambda (urandom)
>               (let ((previous-umask (umask #o077))
>                     (buf (make-bytevector 512)))
>                 (mkdir-p (dirname #$%random-seed-file))
>                 (get-bytevector-n! urandom buf 0 512)
>                 (call-with-output-file #$%random-seed-file
>                   (lambda (seed)
>                     (put-bytevector seed buf)))
>                 (umask previous-umask))))
>
> This comes from commit 71cb237a7d98dafda7dfbb5f3ba7c68463310383 by Leo.
>
> What about deleting the seed instead of populating it right at boot
> time?
>
> That way, we would actually have entropy available at boot time.  In
> case of a crash, the system may lack entropy upon reboot, but that’s
> better than always lacking entropy when booting.
>
> Marius, Leo, WDYT?

I tried it, but it did not make any discernible difference in the
available entropy right after boot, nor did it aid the CRNG seeding.

So I think we should go with Linus' solution for now, as well as your
original fix Ludo because it seems to be the right thing to do anyway.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2019-10-05 12:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 15:48 bug#37501: [core-updates] Entropy starvation during boot Marius Bakke
2019-10-02 13:42 ` Ludovic Courtès
2019-10-02 22:29 ` Ludovic Courtès
2019-10-03 22:10   ` Marius Bakke
2019-10-04  9:01     ` Ludovic Courtès
2019-10-04  9:07   ` Ludovic Courtès
2019-10-04  9:15   ` Ludovic Courtès
2019-10-05 12:56     ` Marius Bakke [this message]
2019-10-05 20:08       ` Ludovic Courtès
2019-10-06 16:42         ` Marius Bakke
2019-10-06 17:38           ` Marius Bakke
2019-10-06 22:03           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pnjb73la.fsf@devup.no \
    --to=mbakke@fastmail.com \
    --cc=37501@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.