From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: bug#37501: [core-updates] Entropy starvation during boot Date: Sun, 06 Oct 2019 19:38:10 +0200 Message-ID: <874l0l7p19.fsf@devup.no> 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: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39485) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iHAUq-00069I-Pz for bug-guix@gnu.org; Sun, 06 Oct 2019 13:39:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iHAUp-0002UF-KD for bug-guix@gnu.org; Sun, 06 Oct 2019 13:39:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:37986) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iHAUp-0002UA-Hf for bug-guix@gnu.org; Sun, 06 Oct 2019 13:39:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iHAUp-0008Iu-Dn for bug-guix@gnu.org; Sun, 06 Oct 2019 13:39:03 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877e5h7rlo.fsf@devup.no> 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 37501-done@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marius Bakke writes: > Ludovic Court=C3=A8s writes: > >> Hi, >> >> Marius Bakke 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=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 > >> 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(?). 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". --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl2aJoIACgkQoqBt8qM6 VPpAJQf+Ljmu97yxmkmEpjglNGdKe/QD78aYxPKCJNRp0HuoLXJCeTuoojsF3VfS nLOBApVJFhp6wXHUuKd12AiLKT87MHtyt1k+SLsBZ8eJiWUEpLXdK9AzVNqjqj7Y H1xrTvUfCLaToYvuCiDwE4VBvLhF8YqXWRAWSJ9Q6Xttf2qiPP1W7MtwZdYw3L7O Arx1uPhsjrjVEKePr66JoyLzmrGQJDsjFVyk9VoxLeOO8lHwsGJ6+6odcNVl9B7V sgP0W/8Vy8BqmZQkyZKDOyjazSHhXDvBbgvyVoD2G6t0l5L0tMnZnAcGcLedsS86 efay+pnAfuKaUcJ3t2uHENCoNV7m5w== =I9IG -----END PGP SIGNATURE----- --=-=-=--