To close off this thread: installing rng-tools5 worked for me. Per guidance in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898814#62
Though I tried, I couldn't verify the particular commit I pointed out was the culprit: with and without that commit got the "crng init done" in ~7.5 seconds repeatedly. And additional code changes in the kernel corrected this issue for most users. With rng-tools5 and debian linux-image-4.19.0-1-amd64 installed, "crng init done" message shows up in 5.9s after booting. cheers, grant On Sun, Dec 23, 2018 at 7:28 PM Grant Grundler <[email protected]> wrote: > > On Sat, Dec 22, 2018 at 12:05 AM Angel Pons <[email protected]> wrote: > > > > Hello, > > > > On Sat, Dec 22, 2018, 08:50 Grant Grundler <[email protected] wrote: > >> > >> On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov <[email protected]> wrote: > >> > > >> > Sorry but I think that relying on Intel RNG is a _Terrible_ idea > >> > regarding the security and not sure you should be pursuing it. > >> > >> What I'm pursueing is a reasonable initialization time so > >> wpa_supplicant can start. 555 seconds is not reasonable: > >> [ 555.496678] random: crng init done > >> [ 555.496678] random: crng init done > >> [ 555.496684] random: 7 urandom warning(s) missed due to ratelimiting > >> [ 560.265385] wlp2s0: authenticate with xx:xx:xx:xx:xx:xx > >> [ 560.279395] wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) > >> [ 560.281981] wlp2s0: authenticated > >> > >> intel-crng was proposed elsewhere as one solution to this problem but > >> it's clear to me now that this is not an option with the panther > >> chromebox. > >> > >> I don't recall seeing this with older kernels (have been running > >> debian on this HW since early 4.x releases) and will look at the > >> driver git logs. > > And I found one commit which I believe is likely the issue (need to > confirm this still): > commit dc12baacb95f205948f64dc936a47d89ee110117 > Author: Theodore Ts'o <[email protected]> > Date: Wed Apr 11 14:58:27 2018 -0400 > > random: use a different mixing algorithm for add_device_randomness() > > This change _could_ cause devices that don't have input or have > wireless networking (which doesn't get initialized until > wpa_supplicants gets a value back from /dev/random) to take a very > long time for crng_init to increment and finally determine "random: > crng init done" (in crng_reseed()). > > But I need to compare v4.17 behavior (where I think this was > introduced) with v4.16 or just revert this with my own 4.18 kernel > build. > > I'm using the following git commands to compare differences in releases: > git diff v4.16..v4.17 -- drivers/char/random.c > git diff v4.17..v4.18 -- drivers/char/random.c > > (same parameters with "log" instead of "diff" to see the corresponding > commit messages) > > ... > >> I experimented with attaching just an optical mouse and that didn't > >> seem to help. > >> Attaching a keyboard and just hitting <shift> key did seem to help > >> ("crng init done" in about 10 seconds). I'm assuming the /dev/random > >> driver is not seeing enough actiivity otherwise. > > > > I have observed the same behavior on Debian Sid, I would have to smash > > my keyboard a few times to generate enough entropy. I don't see anything > > similar with Arch Linux. Maybe it has to do with distro-specific packaging? > > I haven't checked. > > Does Arch-Linux kernel include the CL above? > ie Is Arch linux offering a 4.17 (or later) kernel? > > cheers, > grant > > ps. I realize this is the wrong forum to discuss a fix ... just want > to wrap up the conversation here to confirm my theory that this might > be a coreboot issue is wrong. _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
