On Mon, May 27, 2019 at 4:07 PM Theodore Ts'o <ty...@mit.edu> 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. > > *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.
Really, it's a chicken & egg thing. If people who make userspaces never have an option to design around the correct behavior, they'll continue to rely on the broken behavior. But if we give them a way to compile their kernels with the correct behavior, eventually some userspaces will run fine with it. "But they should just use getrandom()!" you shout. Yes, and maybe the code most userspace builders provide does do this. But people like to plug-in plenty of third party things into their userspaces, and I think there's some value in a userspace being able to say, "we've dealt with the /dev/urandom situation, and we now do the right thing, so we can enable this option, and now the code you run on our userspace will give good randomness." More concretely, distros might ship an init system that allows enabling this option without creating issues. Systemd might improve. OpenRC and runit-based distros appear to exist. Some folks do very custom stuff. If they manage to make it work with the correct urandom behavior, then that's a good situation for everything else to build on, and for providing better guarantees for third party software that runs on that distro. But none of this is possible without the ability to compile the kernel with the correct behavior.
