search

freifunk-gluon / gluon

a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes
https://gluon.readthedocs.io
Other
550 stars 325 forks source link

gluon-core: entropy daemon not available on all platforms #2182

Open blocktrron opened 3 years ago

blocktrron commented 3 years ago

Bug report

What is the problem?

urngd is not compatible with every platform. The timer is to coarse to generate jitter entropy from it on some platforms.

The kernel ringbuffer will in this case read

[   10.250566] urngd: jent-rng init failed, err: 2

This problem exists at least on ramips-mt7620 and bcm-2708.

What is the expected behaviour?

Have an entropy daemon for generating random ssh host keys as well as fastd keys.

Gluon Version:

Gluon 2020.2

Site Configuration:

Not site-dependent if haveged is not included in the site.

Custom patches:

-

neocturne commented 3 years ago

Any ideas how to solve this? Does haveged work on these platforms?

blocktrron commented 3 years ago

Yes, haveged works. AFAIR was haveged only a recommendation in the docs (cit needed), mentioning this in the docs might be fine.

Otherwise, adding a dependency for haveged and removing urngd from the package set is also a viable solution.

neocturne commented 3 years ago

It would be interesting to know if haveged actually produces good entropy on these platforms, and if it does, if urngd can be made to do the same. I can have a look at the code this week, but it's unlikely that I'll find out anything without the hardware in question...

neocturne commented 3 years ago

Upstream jitterentropy-rngd used by urng recently gained a fallback mode for systems without high-resolution timers. We should evaluate if urng can be updated to use the new version without increasing its size too much.

neocturne commented 3 years ago

Well... the fallback mode "works", but urngd now consumes 100% CPU for several minutes on boot (tested on brcm2708).

On brcm2708, urngd is not included by default anymore on OpenWrt master, instead /dev/random is sourced by the hwrng (this seems to be handled fully in kernel now?).

One remaining question would be how to deal with ramips-mt7620 (and other targets with this issue that we don't know of)