From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#37501: [core-updates] Entropy starvation during boot Date: Mon, 07 Oct 2019 00:03:19 +0200 Message-ID: <871rvpbkgo.fsf@gnu.org> References: <87sgolae6l.fsf@devup.no> <87h84qdbmg.fsf@gnu.org> <87y2y0x453.fsf@gnu.org> <87pnjb73la.fsf@devup.no> <87imp3nefk.fsf@gnu.org> <877e5h7rlo.fsf@devup.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44025) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iHEdL-0001fm-EQ for bug-guix@gnu.org; Sun, 06 Oct 2019 18:04:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iHEdK-00007K-9r for bug-guix@gnu.org; Sun, 06 Oct 2019 18:04:07 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:38145) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iHEdF-00006n-TO for bug-guix@gnu.org; Sun, 06 Oct 2019 18:04:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iHEdF-0007HD-N1 for bug-guix@gnu.org; Sun, 06 Oct 2019 18:04:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877e5h7rlo.fsf@devup.no> (Marius Bakke's message of "Sun, 06 Oct 2019 18:42:43 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Marius Bakke Cc: 37501-done@debbugs.gnu.org Hello! Marius Bakke skribis: > Ludovic Court=C3=A8s writes: [...] >> Bah, too bad, though it still doesn=E2=80=99t sound right to consume thi= s much >> entropy right from the start. I=E2=80=99m surprised it doesn=E2=80=99t = 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/ent= ropy_avail=20 > 3693 > [...typing this section of the email...] > $ head -c 512 /dev/urandom > /dev/null && cat /proc/sys/kernel/random/ent= ropy_avail=20 > 3898 Uh! But that=E2=80=99s once the system is running, and with a long-enough = pause in between reads=E2=80=A6 maybe? >> Perhaps we should print the value of /proc/=E2=80=A6/entropy_avail in se= veral >> 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=3D43838a23a05fbd13e47d750d3dfd77001536dd33 > > Once it is initialized, we get an "endless" stream of good random data > thanks to the entropy pool and ChaCha20(?). > > See also this article for an overview of the discussions that lead to > Torvalds' patch: > > https://lwn.net/SubscriberLink/800509/de787577364be340/ Interesting, thanks for the link! > Anyway, I pushed the upstream fix in > dd6989711370c43676edc974f86c8586f21f80f6. Coolio, now merging is no longer blocked due to entropy starvation! :-) Ludo=E2=80=99.