[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2508489.jOnZlRuxVn@merkaba>
Date: Tue, 17 Sep 2019 09:33:40 +0200
From: Martin Steigerwald <martin@...htvoll.de>
To: Willy Tarreau <w@....eu>
Cc: Matthew Garrett <mjg59@...f.ucam.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Ahmed S. Darwish" <darwish.07@...il.com>,
"Theodore Y. Ts'o" <tytso@....edu>,
Vito Caputo <vcaputo@...garu.com>,
Lennart Poettering <mzxreary@...inter.de>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
William Jon McCann <mccann@....edu>,
"Alexander E. Patrakov" <patrakov@...il.com>,
zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8
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
Powered by blists - more mailing lists