On Di, 17.09.19 08:11, Theodore Y. Ts'o (tytso@mit.edu) wrote:
On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
quoted
Willy Tarreau - 17.09.19, 07:24:38 CEST:
quoted
On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
quoted
quoted
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