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] https://mail.coreboot.org/mailman/listinfo/coreboot
