3 ms·
> Systemd is literally the only software, that has this problem. I am not aware of any other software, that uses rdrand and expects high-quality cryptography-gr
by tadfisher 6y ago
> Systemd is literally the only software, that has this problem. I am not aware of any other software, that uses rdrand and expects high-quality cryptography-grade randomness.
Please seek out and understand the reasons behind calling RDRAND in systemd before making statements like these. "High-quality crytography-grade randomness" is explicitly not required for the purposes of the PRNG at boot-time, which include UUID generation and seeding hash tables.
https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbfeb75b530539c4834f6a4/src/basic/random-util.c#L40-L98 https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbf...
- tremon 6y agoWhy would the boot process need to generate UUID's? And even if it does, why would it need truly random UUIDv4s instead of simple UUIDv1s?
- LukeShu 6y agoUUIDv1s (RFC 4122 §4.2.1) also rely on several things that are even less likely to be available at early-boot: - The clock might not be initialized; the justification for using rdrand specifically calls out embedded systems; embedded systems are also likely to have clocks that reset to some date every boot and get fixes as part of the boot process that happens later. - The "node ID" (nominally, a MAC address) udev has not started yet and therefore has not initialized the network cards yet (in fact, if you configure it to randomize your MAC address (for privacy), the random_bytes() routine being discussed is the one that it will use to generate the MAC!) The filesystem hasn't yet been mounted, it can't use /etc/machine-id or anything like that either.