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 grantgrundler@gmail.com wrote:
On Sat, Dec 22, 2018 at 12:05 AM Angel Pons th3fanbus@gmail.com wrote:
Hello,
On Sat, Dec 22, 2018, 08:50 Grant Grundler <grantgrundler@gmail.com wrote:
On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov qmastery16@gmail.com 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 tytso@mit.edu 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.