[coreboot] Asus Chromebox Panther: no HW RNG?

[Grant Grundler]

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