8

CPU is AMD GX-412TC SOC:

GX-412TC GE412TIYJ44JB 4 6W 2MB 1.0GHz/ 1.4GHz N/A N/A DDR-1333 0-90°C

which does not have rdrand:

grep rdrand /proc/cpuinfo
# nothing

I see following messages in my syslog after machine boot:

kernel: random: dd: uninitialized urandom read (512 bytes read)
kernel: random: cryptsetup: uninitialized urandom read (32 bytes read)

what exactly do these messages mean, and what can I do about it?

Does it mean dd and cryptsetup try to read from /dev/urandom, but there is not enough entropy?

I am using haveged daemon, but it is started late in the boot process, after this message appears.

Here is my boot script startup sequence:

/etc/rcS.d/S01hostname.sh
/etc/rcS.d/S01mountkernfs.sh
/etc/rcS.d/S02mountdevsubfs.sh
/etc/rcS.d/S03checkroot.sh
/etc/rcS.d/S04checkfs.sh
/etc/rcS.d/S05mountall.sh
/etc/rcS.d/S06bootmisc.sh
/etc/rcS.d/S06procps
/etc/rcS.d/S06urandom
/etc/rcS.d/S07crypto-swap
/etc/rc2.d/S01haveged
/etc/rc2.d/S01networking
/etc/rc2.d/S04rsyslog
/etc/rc2.d/S05cron
/etc/rc2.d/S05ssh

the messages in syslog come from these two scripts:

/etc/rcS.d/S06urandom  -> dd
/etc/rcS.d/S07crypto-swap -> cryptsetup

Should haveged be started before urandom ?

I am using Debian 10.

Also, I should add that this machine is a bare board, with no keyboard. The only interface is a serial console. I think this has an effect on the available entropy, and is the reason why I have installed haveged in the first place. Without haveged, the sshd daemon would not start for several minutes, because it does not have enough entropy.

Improve this question
8
  • Try to uninstall haveged and install what I suggested, it should solve your problem, but I'm specializing on Intel, so I don't know much of AMD. If unsuccessful, you can always revert to haveged. Commented Oct 26, 2021 at 7:10
  • packages.debian.org/buster/rng-tools5 Commented Oct 26, 2021 at 7:28
  • Sorry, your CPU does not have rdrand, in which case my suggestion will likely not help, but you may try it of course if you wish. Commented Oct 26, 2021 at 7:44
  • For documentation, it might be helpful to go through this GitHub issue thread, which explains a lot. Commented Oct 26, 2021 at 7:48
  • 1
    /dev/urandom is pseudo random generator and cannot block (even if it runs out of entropy) in contrast to /dev/random. see security.stackexchange.com/questions/89/… Commented Oct 26, 2021 at 13:20

2 Answers 2

Reset to default
5

Your diagnosis is correct: a read was attempted on an empty entropy pool. This is "boot time entropy starvation".

You can either leverage systemd-boot if you have an EFI system, ignore the warning (you're using a predictable crypto, but in most use cases that's still better than no crypto at all), or try crediting entropy from alternate sources - if available - adding this to the kernel command line

rng_core.default_quality=X

(start at X=1000 and go down from there).

There are other techniques to collect entropy; a SOC might have some pins available and there are hardware driver modules that allow collecting entropy from them. It is then just a matter of connecting some suitable transistor-and-resistor setup (or in some cases, an electret mic) to gather some thermal noise.

Alternately, the 5.4+ series kernels have a more efficient entropy collection which might be enough.

Improve this answer
2

For haveged to work, it has to be compatible with your kernel — there's an issue with haveged not doing anything in kernel versions >=5.x, see is haveged still useful/relevant? #57 on GitHub.

The maintainer was kind enough to re-introduce functionality but those patches will have to be released and then make it into the various distros first... the old version either won't start at all or won't actually do anything even if it's running (check with strace), as the kernel's entropy pool no longer seems to be lacking — but crng init still takes time for some reason.

It also has to run very early on, so if you are using initramfs, then you also have to start haveged in initramfs, some time before using the random device. In a traditional init system, haveged should run as soon as /proc /sys /dev is available.

I'm not sure how long haveged takes exactly to send entropy to the kernel... it has to harvest randomness on its own first and it runs some quality tests on that too. In my last test (with patched haveged) there was like half a second delay between starting haveged and kernel reporting random: crng init done.

In addition to haveged, you can also consider saving/restoring a random seed, and if you have network, a little bit of traffic might help the kernel to collect some entropy as well.

Improve this answer
2
  • thank you. I am using custom kernel 5.10.82, and haveged version 1.9.1-7. Does it mean I have to upgrade haveged to latest version? Commented Jan 6, 2022 at 7:28
  • @400theCat with haveged 1.9.16 you can use haveged --once in initramfs - github.com/jirka-h/haveged/releases/tag/v1.9.16 . another alternative (discussed in the github haveged bug #57) might be to use /dev/random instead of /dev/urandom because for some reason, kernel 5.6+ only uses jitter entropy for the former and not the latter. OTOH /dev/random might block, you'll just have to try and see for yourself. Using haveged (and random seed) is my personal preference... Commented Jan 6, 2022 at 8:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.