On Mon, May 27, 2019 at 10:06:43AM -0400, Theodore Ts'o wrote: >> [...] > > This is guaranteed to cause the system to fail for systems using > systemd. (Unless you are running an x86 with random.trust_cpu=1 --- > in which case, this patch/config is pointless.) And many embedded > systems *do* use systemd. I know lots of people like to wish that > systemd doesn't exist, but we need to face reality.
Hence a compile-time option; systemd systems need not use it yet. I would argue systemd needs to fix their randomness API (it's a sad joke), and use secure randomness only where required. For example, it is said that systemd relies on randomness to generate unique UUIDs where a UUIDv4 would suffice. I'm happy to add a disclaimer in the kernel config that this will break systemd. > *Seriously,* if this is something the system builder should be using, > they should be fixing userspace. And if they care enough that they > would want to enable this patch, they could just scan dmesg looking > for the warnings from the kernel. And I think this is the more interesting case, system builders should ideally fix userspace and rely on getrandom (which is no different to this compile time option). But the reality is the boot entropy hole problem has been the source of many insecure cryptographic keys, and this provides a simple assurance that it can no longer be the cause of these issues (supposing good entropy is gathered). - Naveen
