Message-ID: <4727002.QyS4NGTWcj@merkaba>
Date:   Tue, 17 Sep 2019 09:15:35 +0200
From:   Martin Steigerwald <martin@...htvoll.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        "Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
        Vito Caputo <vcaputo@...garu.com>,
        "Ahmed S. Darwish" <darwish.07@...il.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: a sane approach to random numbers (was: Re: Linux 5.3-rc8)

As this is not about Linux 5.3-rc8 anymore I took the liberty to change 
the subject.

Linus Torvalds - 17.09.19, 01:05:47 CEST:
> On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett <mjg59@...f.ucam.org> 
> wrote:
> > The semantics many people want for secure key generation is urandom,
> > but with a guarantee that it's seeded.
> 
> And that is exactly what I'd suggest GRND_SECURE should do.
> 
> The problem with:
> > getrandom()'s default behaviour at present provides that
> 
> is that exactly because it's the "default" (ie when you don't pass any
> flags at all), that behavior is what all the random people get who do
> *not* really intentionally want it, they just don't think about it.
> > Changing the default (even with kernel warnings) seems like
> > it risks people generating keys from an unseeded prng, and that
> > seems
> > like a bad thing?
> 
> I agree that it's a horrible thing, but the fact that the default 0
> behavior had that "wait for entropy" is what now causes boot problems
> for people.

Seeing all the discussion, I just got the impression that it may be best 
to start from scratch. To stop trying to fix something that was broken to 
begin with – at least that was what I got from the discussion here.

Do a sane API with new function names, new flag names and over time 
deprecate the old one completely so that one day it hopefully could be 
gradually disabled until it can be removed. Similar like with statx() 
replacing stat() someday hopefully.

And do some documentation about how it is to be used by userspace 
developers. I.e. like: If the kernel says it is not random, do not block 
and poll on it, but do something to generate entropy.

But maybe that is naive, too.

However, in the end, what ever you kernel developers will come up with, 
I bet there will be no way to make the kernel control userspace 
developers. However I have the impression that that is what you attempt 
to do here. As long as you have an API to obtain guaranteed random 
numbers or at least somewhat guaranteed random numbers that is not 
directly available at boot time, userspace could poll on its 
availability. At least as long as the kernel would be honest about its 
unavailability and tell about it. And if it doesn't applications that 
*require* random numbers can never know whether they got some from the 
kernel.

Maybe you can make an API that is hard to abuse, yes. And that is good. 
But impossible?

I wonder: How could the Linux experience look like if kernel developers 
and userspace developers actually work together instead of finding ways 
to fight each other? I mean, for the most common userspace applications 
in the free software continuum, there would not be all that many people 
to talk with, or would there? It is basically gdm, sddm, some other 
display managers probably, SSH, GnuPG and probably a few more. For 
example for gdm someone could open a bug report about its use of the 
current API and ask it to use something that is non blocking? And does 
Systemd really need to deplete the random pool early at boot in order to 
generate UUIDs? Even tough I do not use GNOME I'd be willing to help 
with doing a few bug reports there and there. AFAIR there has been 
something similar with sddm which I used, but I believe there it has 
been fixed already with sddm.

Sometimes I wonder what would happen if kernel and userspace developers 
actually *talk* to each other, or better *with* each other.

But instead for example with Lennart appears to be afraid to interact 
with the kernel community and some kernel developers just talked about 
personalities that they find difficult to interact it, judging them to be 
like this and like that.

There is a social, soft skill issue here that no amount of technical 
excellence will resolve. That is at least how I observe this.

Does it make it easier? Probably not. I fully appreciate that some 
people may have a difficult time to talk with each other, I experienced 
this myself often enough. I did not report a bug report with Systemd I 
found  recently just cause I do not like to repeat the experience I had 
when I reported bugs about it before and I do not use it anymore 
personally anyway. So I totally get that.

However… not talking with each other is not going to resolve those 
userspace uses kernel API in a way kernel developers do not agree with 
and that causes issues like stalled boots. Cause basically userspace can 
abuse any kernel API and in the end the kernel can do nothing about it.

Of course feel free to ignore this, if you think it is not useful.

Thanks,
-- 
Martin

Powered by blists - more mailing lists