bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37501: [core-updates] Entropy starvation during boot


From: Marius Bakke
Subject: bug#37501: [core-updates] Entropy starvation during boot
Date: Sat, 05 Oct 2019 14:56:49 +0200
User-agent: Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu)

Ludovic Courtès <address@hidden> writes:

> Ludovic Courtès <address@hidden> 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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]