Interesting. So if I use systemd-boot, I always get an initialized pool during early boot, that sounds good. Perhaps systemd should take that into account and skip rdrand entirely if the pool initialization is guaranteed.
> This is the advantage you have when you're building an entire operating system, not just a kernel.
I'm now convinced that systemd really is an operating system.
As far as I can see, systemd still attempts to use rdrand for UUIDs regardless of how /dev/urandom is initialized. Perhaps a solution less vulnerable to the rdrand problem, is to use getrandom() directly if the pool is guaranteed to be initialized (but still, very few users can benefit from it due to the limited deployment of systemd-boot).
> When generating Type 4 UUIDs, systemd tries to use Intel’s and AMD’s RDRAND CPU opcode directly, [...] If RDRAND is not available or doesn’t work, it will use synchronous getrandom() as fallback, and /dev/urandom on old kernels where that system call doesn’t exist yet. This means on non-Intel/AMD systems UUID generation will block on kernel entropy initialization.
> This is the advantage you have when you're building an entire operating system, not just a kernel.
I'm now convinced that systemd really is an operating system.