Problems emerge for a unified /dev/*random

Posted Apr 1, 2022 9:07 UTC (Fri) by wsy (subscriber, #121706)
In reply to: Problems emerge for a unified /dev/*random by wtarreau
Parent article: Problems emerge for a unified /dev/*random

I would never trust a boot loader unless it's open source. And I don't think SOC vendors will do that.

Problems emerge for a unified /dev/*random

Posted Apr 1, 2022 10:06 UTC (Fri) by nickleverton (subscriber, #81592) [Link] (1 responses)

U-Boot, which I would guess is probably used by most embedded devices that boot into Linux, is GPL2.0+. It's ideally placed to extract the early boot hardware-based randomness that Willy Tarreau mentions, running after any SoC ROM loader but before the Linux kernel. I am sure Grub could do similar things for bigger SoCs that boot from disk.

Problems emerge for a unified /dev/*random

Posted Apr 1, 2022 12:07 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

Yes U-Boot definitely is the best place here, since it often embeds the SPL code that's used to train the DDR memory. Typically the training is a good way to produce entropy since it tries timings for reliable transfers.

For the PC world, grub might be too late due to the BIOS often doing most of the cleanup. However on PCs there's often a video card whose memory is not reset and which contains garbage. I think it already happened to all of us to power-cycle a PC, then discover a fantom image of previous session for a fraction of a second when typing "startx" because that memory wasn't completely lost yet. And most PCs have hardware RNGs and jitter entropy anyway ;-)