Re: Asus Chromebox Panther: no HW RNG?

[Grant Grundler]

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  wrote:
> On Sat, Dec 22, 2018 at 12:05 AM Angel Pons  wrote:
> > Hello,
> >
> > On Sat, Dec 22, 2018, 08:50 Grant Grundler <[e-mail] wrote:
> > > On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov  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 
> 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.