On 9/19/23 02:20, Sam Liddicott wrote: > This is also a problem with many virtual appliances. There is no easy answer > to > this kernel bootup entropy problem and it is lamentable that solutions are > delegated to user space, and even to scripts, and to non-experts who will do a > bad job of it but not know it. > > You may as well feed what random data you have into rngd which will supply it > to > the kernel. You may as well feed /dev/urandom back, as has been pointed out, > it > is well-hashed (though then stretched) original entropy.
If it's not initialized by anything you get the same results each run, which generates the same keys during boot, which makes cryptographic attacks on recorded sessions way easier. The only source of variance is the battery backed up clock (when there is one, not all hardware...) and timing jitter in a boot cycle you're trying to make as fast as possible (the record is something like 2/3 of a second). Other historical sources like the network card's mac address stopped being mixed in by drivers because "I am nomad, I am perfect, you must be eliminated" reasoning. (So userspace had to do it via "ifconfig -a > /dev/random" and friends... which is exactly what they nerfed, because nomad.) Imagine a mass produced 25 cent board with basically a rom image and no battery (batteries die, batteries leak acid, batteries age poorly when heated, batteries cost money and take up space), which netboots via public key cryptography (or even just fetches provisioning data that won't fit in 1k of cheap on-chip flash). If it can't generate session keys right after boot, there's a problem. Modern "software" entropy collection is mostly timing jitter collected very slowly as the system runs. The theory for embedded devices was if you have some writeable space in the device you save a few hundred bytes of /dev/urandom output on shutdown and write it back on bootup so you're keeping enough entropy across reboots to seriously salt your attack surface. The perfect is the enemy of the good: this just makes different boots behave differently. I honestly don't understand what creating a new API for this is supposed to do. Supplying the information via ioctl is superior to supplying the same information via /dev or /sys how exactly? Rob _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
