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: Fri, 04 Oct 2019 11:01:13 +0200 Message-ID: <87h84oyjdy.fsf@gnu.org> References: <87sgolae6l.fsf@devup.no> <87h84qdbmg.fsf@gnu.org> <87zhih7a5m.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]:47152) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGJTQ-0006RI-8q for bug-guix@gnu.org; Fri, 04 Oct 2019 05:02:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iGJTO-0004nP-Ho for bug-guix@gnu.org; Fri, 04 Oct 2019 05:02:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:32920) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iGJTO-0004nJ-CZ for bug-guix@gnu.org; Fri, 04 Oct 2019 05:02:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iGJTO-0003tZ-7f for bug-guix@gnu.org; Fri, 04 Oct 2019 05:02:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87zhih7a5m.fsf@devup.no> (Marius Bakke's message of "Fri, 04 Oct 2019 00:10:29 +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@debbugs.gnu.org Hi Marius, Marius Bakke skribis: > Ludovic Court=C3=A8s writes: [...] >> I read some of these, and our =E2=80=98urandom-seed-service-type=E2=80= =99 has the same >> bug as . Namely, we >> write the previous seed to /dev/urandom but we don=E2=80=99t credit the >> entropy. >> >> The attached patch fixes that, and I think it should fix the problem you >> reported. Could people give it a try? > > Good catch, LGTM. Unfortunately it does not fix the problem. > >> I=E2=80=99m interested in seeing the value of >> /proc/sys/kernel/random/entropy_avail with and without this patch right >> after boot (don=E2=80=99t try it in =E2=80=98guix system vm=E2=80=99 bec= ause there=E2=80=99s no seed >> there.) > > before - 243 > after - 2419 Is that with or without sshd running? Do we have strong evidence that sshd is stuck in getrandom(2)? That seems weird to me because we use #:pid-file for sshd, and thus either sshd produces its PID file and we=E2=80=99re done (=E2=80=98ssh-daem= on=E2=80=99 is considered started and life goes on), or sshd fails to produce its PID file within 15 seconds and we kill it and consider that =E2=80=98ssh-daemon= =E2=80=99 failed to start. This only way this can hang is if sshd calls getrandom(2) before daemonizing. Looking at =E2=80=98main=E2=80=99 in sshd.c, I see: seed_rng(); [=E2=80=A6] already_daemon =3D daemonized(); which I think means sshd indeed calls getrandom(2) before it has forked. That explains the situation. :-/ (=E2=80=98seed_rng=E2=80=99 uses =E2=80=98RAND_status=E2=80=99 from OpenSSL= , which supports several methods but presumably defaults to getrandom(2)?) > I don't know why this change was insufficient. Perhaps the kernel > does not consider such a seed alone trustworthy enough? I also tried to > increase the seed size to no avail. Can you try to do: (add-to-entropy-count urandom (expt 2 17)) to see if that changes anything at all? I checked with strace and the RNDADDTOENTCNT binding seems to be passing its argument as expected. > I found this patch in the 5.4 kernel tree after reading the commit log > of random.c: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D3f2dc2798b81531fd93a3b9b7c39da47ec689e55 > > ...which *does* solve the problem. > > The comments in the merge commit suggests that it is not necessarily a > good solution, so I think we should let it "settle" a bit upstream > before pushing it. It does look rather sledgehammer-y... > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3D3f2dc2798b81531fd93a3b9b7c39da47ec689e55 > > Thoughts? If it has to be that way, we can use this patch and we can always remove it later if we have a better solution. At any rate, I=E2=80=99d rather not block =E2=80=98core-updates=E2=80=99 an= y longer. Thoughts? Thanks for investigating! Ludo=E2=80=99.