On Di, 17.09.19 08:11, Theodore Y. Ts'o (tytso@xxxxxxx) wrote: > On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote: > > 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. > > > > I would be happy with a change which changes getrandom(0) to send a > kill -9 to the process if it is called too early, with a new flag, > getrandom(GRND_BLOCK) which blocks until entropy is available. That > leaves it up to the application developer to decide what behavior they > want. Note that calling getrandom(0) "too early" is not something people do on purpose. It happens by accident, i.e. because we live in a world where SSH or HTTPS or so is run in the initrd already, and in a world where booting sometimes can be very very fast. So even if you write a program and you think "this stuff should run late I'll just getrandom(0)" it might not actually be that case IRL because people deploy it a slightly bit differently than you initially thought in a slightly differently equipped system with other runtime behaviour... Lennart
