Problems emerge for a unified /dev/*random

Posted Mar 30, 2022 21:22 UTC (Wed) by istenrot (subscriber, #69564)
Parent article: Problems emerge for a unified /dev/*random

Why don't we generate during a kernel build a sufficiently large kernel embedded binary blob to be used as good quality pre-boot stage random seed? Then mixed with hardware unique identifiers like network interface MAC addresses, SMBIOS data, hardware sensors, RTC time, etc we should have quite nice pre-boot random source. Right?

Problems emerge for a unified /dev/*random

Posted Mar 30, 2022 21:46 UTC (Wed) by mb (subscriber, #50428) [Link] (1 responses)

Except that it would be the same on every early boot.
And it would even be the same for every distro kernel (minus the mac, whatever mixing).

Problems emerge for a unified /dev/*random

Posted Mar 31, 2022 10:51 UTC (Thu) by nix (subscriber, #2304) [Link]

... and the whole problem here is that on some platforms there *is* no varying "MAC, whatever" to mix in, and those are the same platforms which are having trouble now. So this would add complexity to... not solve the problem at all :)

Problems emerge for a unified /dev/*random

Posted Apr 1, 2022 0:50 UTC (Fri) by zx2c4 (subscriber, #82519) [Link]

From this commit message:

Additionally, the plugin can pre-initialize arrays with build-time random contents, so that two different kernel builds running on identical hardware will not have the same starting values.