[SOLVED] "uninitialized urandom read" warnings in kernel 5.15.117

Projectile · 07-05-2023, 05:26 AM

The below warnings appear during each boot, ever since the kernel was upgraded from 5.15.19 to 5.15.117:

Code:

[ --- ] random: udevd: uninitialized urandom read (16 bytes read)
[ --- ] random: udevd: uninitialized urandom read (16 bytes read)
[ --- ] random: udevd: uninitialized urandom read (16 bytes read)
[ --- ] random: cryptsetup: uninitialized urandom read (4 bytes read)
[ --- ] random: cryptsetup: uninitialized urandom read (4 bytes read)

Are these warnings something to worry about security-wise?

henca · 07-05-2023, 12:51 PM

The above messages means that you are using a predictable crypto because of "boot time entropy starvation". There is some information on how to avoid that at https://wiki.debian.org/BoottimeEntropyStarvation

regards Henrik

GazL · 07-05-2023, 01:51 PM

Quote:

Originally Posted by henca

The above messages means that you are using a predictable crypto because of "boot time entropy starvation". There is some information on how to avoid that at https://wiki.debian.org/BoottimeEntropyStarvation

regards Henrik

The volume key is generated at creation time, not open time. I'm not entirely sure what cryptsetup uses those 8 bytes of randomness for, but unless his adversary is a State level TLA Agency it's probably not a big deal that urandom isn't fully initialised.

That said, on my laptop my crng pool is initialised within the first 1/10th of a second of boot, well before udev is started by the initrd, so I'm surprised he's hitting this issue.

I used to see these messages prior to the jitter routines being added in kernel 5.4, but I haven't seen them show up since.

Projectile · 07-11-2023, 02:43 AM

Apparently my CPU doesn't have rdrand? Checking for it yields:

Code:

$ grep CONFIG_RANDOM_TRUST_CPU /boot/config-generic-5.15.117.x64 && grep rdrand /proc/cpuinfo && echo "your system looks fine"
CONFIG_RANDOM_TRUST_CPU=y
$

Any ideas how to fix the "boot time entropy starvation"? I need a solution that works on Slackware 15, please.

EDIT: also, I double-checked and these warnings do appear in kernel 5.15.19 as well so the first post is misleading, sorry.

Petri Kaukasoina · 07-11-2023, 04:05 AM

You could try to 'cp /sbin/haveged /boot/initrd-tree/sbin' and add line 'haveged --once' to the script /boot/initrd-tree/init at line 98 after proc, sysfs, devtmpfs have been mounted. Then run a plain 'mkinitrd' without options to build /boot/initrd.gz with otherwise previous initrd content and use it. Do not use the '-c' flag with mkinitrd command because it clears initrd-tree and removes your changes. (If cleared, mkinitrd extracts a new initrd-tree from /usr/share/mkinitrd/initrd-tree.tar.gz where your changes are not yet.)

I have not tested it. So, I would make a copy of the old initrd.gz to a different name and use it as a backup choice in the boot menu of my boot loader.

EDIT: Now I have tested it on my machine which does not have problems with urandom. It booted normally as before.

Projectile · 07-11-2023, 08:34 AM

Petri Kaukasoina, I have followed your instructions but unfortunately the warning messages are unaffected:

Deleted /boot/initrd.gz
Copied haveged into /boot/initrd-tree/sbin/
Edited /boot/initrd-tree/init to call `haveged --once` at line 99
Ran `# mkinitrd`
Checked that the new initrd.gz contains haveged and the edited init script (yes)
Ran `# lilo` (/etc/lilo.conf boots /boot/vmlinuz-generic and uses /boot/initrd.gz)

Later I have also tried calling `/sbin/haveged --once`, which made no difference.
`# dmesg -H` shows no mention of "haveged".

Maybe, the call to haveged is being ignored?

Petri Kaukasoina · 07-11-2023, 01:58 PM

Please try this as the haveged command in /boot/initrd-tree/init, line 98:

Code:

haveged -n 512 -f /dev/urandom

instead of 'haveged --once'. (And run mkinitrd and lilo.)

Petri Kaukasoina · 07-11-2023, 02:17 PM

I just tested that here. I also added line 'sleep 10' after that haveged line, so I could read the output. During boot it printed 'Writing 512 output to /dev/urandom'.

Projectile · 07-12-2023, 04:24 AM

No difference: same warnings like in the first post.
In addition I have also tried (fruitlessly):

Code:

haveged --once
haveged --number=4096 --file=/dev/random
haveged --number=4096 --file=/dev/urandom
sleep 10

Thank you for trying to help.

Petri Kaukasoina · 07-12-2023, 05:25 AM

Maybe not a good idea, but you could try a longer sleep. And during the sleep you could hit the shift and alt keys a lot and move the mouse a lot. Maybe the interrupts generate enough entropy. (Maybe the os does not trust the quality of entropy fed to /dev/*random.)

GazL · 07-12-2023, 05:45 AM

If you want to force the initrd to wait until the rng has initialised then you can compile this simple program and add it to the start of your initrd:

Code:

#include <stdio.h>
#include <sys/random.h>

int main()
{
    unsigned char r;
    puts("Waiting for random number generator to initialise...");
    return getentropy(&r, sizeof r);
}

The getentropy() call will not return until the kernel rng has initialised. Depending on how well your system gathers entropy this could introduce a short delay, or in the worst case, where no entropy sources are available at all, block the boot indefinitely. On x86 the kernel gathers entropy from CPU timing jitter and interrupts, other archs may not be so lucky.

If you give this a go, make sure you have an alternate initrd to boot from just in case it doesn't return.

GazL · 07-12-2023, 05:48 AM

Quote:

Originally Posted by Petri Kaukasoina

Maybe the os does not trust the quality of entropy fed to /dev/*random

More recent kernels no longer increase the entropy count when you write to /dev/random, though the data itself is still merged into the pools.

Projectile · 07-12-2023, 07:10 AM

GazL, thank you! This fixed all the warnings.

I am marking this thread as "Solved" however I do find it curious that your solution introduced no delay in the boot process and yet `sleep 10` didn't help at all.

GazL · 07-12-2023, 09:22 AM

Yes, that is a little odd, but then again 'sleep' doesn't really get the kernel to do much, no matter how long it waits. I guess the getentropy() call managed to get the kernel to do just enough work to generate enough entropy to get the job done: kind of like a self-fulfilling prophecy.

Anyway, glad it worked for you.

BTW, dmesg | grep 'crng init done' will show you the exact timings.

GazL · 07-12-2023, 09:36 AM

P.S. this whole thing makes me wonder if carrying over the /etc/random-seed data from one boot to the next is really of any value any more. The kernel periodically reseeds the chacha20 CSPRNG generators now anyway and /dev/random no longer has an 'entropy pool' as such that it draws from.