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: Sun, 06 Oct 2019 19:38:10 +0200
User-agent: Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu)

Marius Bakke <address@hidden> writes:

> Ludovic Courtès <address@hidden> writes:
>
>> Hi,
>>
>> Marius Bakke <address@hidden> skribis:
>>
>>> 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.
>>
>> Bah, too bad, though it still doesn’t sound right to consume this much
>> entropy right from the start.  I’m surprised it doesn’t make any
>> difference when you remove that bit.
>
> I guess generating 512 random bytes does not cost a lot of entropy.
> Writing that made me curious, so I tested it:
>
> $ cat /proc/sys/kernel/random/entropy_avail
> 3938
> $ head -c 512 /dev/urandom > /dev/null && !!
> 3947
>
> Wait, what?  Trying again...
>
> $ head -c 512 /dev/urandom > /dev/null && cat 
> /proc/sys/kernel/random/entropy_avail 
> 3693
> [...typing this section of the email...]
> $ head -c 512 /dev/urandom > /dev/null && cat 
> /proc/sys/kernel/random/entropy_avail 
> 3898
>
>> Perhaps we should print the value of /proc/…/entropy_avail in several
>> places during boot time to get a better understanding.
>
> That could be useful.  My understanding is that we were waiting for the
> kernel to be absolutely certain that the entropy pool is sufficiently
> random, i.e. "state 2" from this overview:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33
>
> Once it is initialized, we get an "endless" stream of good random data
> thanks to the entropy pool and ChaCha20(?).

Answering a question I got from reading my own email: I guess the reason
we can read from /dev/urandom before getrandom(2) works, is that
/dev/urandom does not require the CRNG to be in "state 2".

Attachment: signature.asc
Description: PGP signature


reply via email to

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