Willy Tarreau - 17.09.19, 07:24:38 CEST: > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote: > > >Well, the patch actually made getrandom() return en error too, but > > >you seem more interested in the hypotheticals than in arguing > > >actualities.> > > If you want to be safe, terminate the process. > > This is an interesting approach. At least it will cause bug reports in > application using getrandom() in an unreliable way and they will > check for other options. Because one of the issues with systems that > do not finish to boot is that usually the user doesn't know what > process is hanging. A userspace process could just poll on the kernel by forking a process to use getrandom() and waiting until it does not get terminated anymore. And then it would still hang. So yes, that would it make it harder to abuse the API, but not impossible. Which may still be good, I don't know. Either the kernel does not reveal at all whether it has seeded CRNG and leaves GnuPG, OpenSSH and others in the dark, or it does and risk that userspace does stupid things whether it prints a big fat warning or not. Of course the warning could be worded like: process blocking on entropy too early on boot without giving the kernel much chance to gather entropy. this is not a kernel issue, report to userspace developers And probably then kill the process, so at least users will know. However this again would be burdening users with an issue they should not have to care about. Unless userspace developers care enough and manage to take time to fix the issue before updated kernels come to their systems. Cause again it would be users systems that would not be working. Just cause kernel and userspace developers did not agree and chose to fight with each other instead of talking *with* each other. At least with killing gdm Systemd may restart it if configured to do so. But if it doesn't, the user is again stuck with a non working system until restarting gdm themselves. It may still make sense to make the API harder to use, but it does not replace talking with userspace developers and it would need some time to allow for adapting userspace applications and services. -- Martin
