4 ms·

>How OpenBSD solved it? Instead of loading it after boot in userspace, OpenBSD load the file early, really early, via the bootloader! Seeding the entropy pool v

>How OpenBSD solved it? Instead of loading it after boot in userspace, OpenBSD load the file early, really early, via the bootloader! Seeding the entropy pool via a file is part of the boot protocol. I thought systemd-boot implemented this as well these days? >During early OS boot the system manager reads this variable and passes it to the OS kernel's random pool, crediting the full entropy it contains. This is an efficient way to ensure the system starts up with a fully initialized kernel random pool — as early as the initial RAM disk phase. https://man.archlinux.org/man/core/systemd/systemd-boot.7.en https://man.archlinux.org/man/core/systemd/systemd-boot.7.en https://systemd.io/RANDOM_SEEDS/ https://systemd.io/RANDOM_SEEDS/

segfaultbuserr 6y ago
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.
- Foxboron 6y ago
  If you set the option to load the seed, yes. That is how I understand it at least!
  - segfaultbuserr 6y ago
    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.

segfaultbuserr 6y ago

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.

Foxboron 6y ago
If you set the option to load the seed, yes. That is how I understand it at least!
- segfaultbuserr 6y ago
  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.