On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett <[email protected]> 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.
Linus
On Mon, Sep 16, 2019 at 04:05:47PM -0700, Linus Torvalds wrote:
> On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett <[email protected]> wrote:
> > 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.
In one case we have "Systems don't boot, but you can downgrade your
kernel" and in the other case we have "Your cryptographic keys are weak
and you have no way of knowing unless you read dmesg", and I think
causing boot problems is the better outcome here.
--
Matthew Garrett | [email protected]
17.09.2019 04:11, Matthew Garrett пишет:
> In one case we have "Systems don't boot, but you can downgrade your
> kernel"
You can't. There are way too many dedicated server providers where there
is no IPMI or any equivalent, and the only help that the staff can do is
to reinstall, wiping your data.
--
Alexander E. Patrakov
On Tue, Sep 17, 2019 at 04:13:36AM +0500, Alexander E. Patrakov wrote:
> 17.09.2019 04:11, Matthew Garrett пишет:
> > In one case we have "Systems don't boot, but you can downgrade your
> > kernel"
>
> You can't. There are way too many dedicated server providers where there is
> no IPMI or any equivalent, and the only help that the staff can do is to
> reinstall, wiping your data.
In which case you're presumably running a distro kernel that's had a
decent amount of testing before you upgrade to it?
--
Matthew Garrett | [email protected]
On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett <[email protected]> wrote:
>
> In one case we have "Systems don't boot, but you can downgrade your
> kernel" and in the other case we have "Your cryptographic keys are weak
> and you have no way of knowing unless you read dmesg", and I think
> causing boot problems is the better outcome here.
Or: In one case you have a real and present problem. In the other
case, people are talking hypotheticals.
Linus
On Mon, Sep 16, 2019 at 04:18:00PM -0700, Linus Torvalds wrote:
> On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett <[email protected]> wrote:
> >
> > In one case we have "Systems don't boot, but you can downgrade your
> > kernel" and in the other case we have "Your cryptographic keys are weak
> > and you have no way of knowing unless you read dmesg", and I think
> > causing boot problems is the better outcome here.
>
> Or: In one case you have a real and present problem. In the other
> case, people are talking hypotheticals.
>
Linus, in all honesty, the other case is _not_ a hypothetical . For
example, here is a fresh comment on LWN from gnupg developers:
https://lwn.net/Articles/799352
It's about this libgnupg code:
=> https://dev.gnupg.org/source/libgcrypt.git
=> random/rdlinux.c:
/* If we have a modern operating system, we first try to use the new
* getentropy function. That call guarantees that the kernel's
* RNG has been properly seeded before returning any data. This
* is different from /dev/urandom which may, due to its
* non-blocking semantics, return data even if the kernel has
* not been properly seeded. And it differs from /dev/random by never
* blocking once the kernel is seeded. */
#if defined(HAVE_GETENTROPY) || defined(__NR_getrandom)
do {
...
ret = getentropy (buffer, nbytes);
...
} while (ret == -1 && errno == EINTR);
thanks,
--
Ahmed Darwish
http://darwish.chasingpointers.com
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds <[email protected]> wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett <[email protected]>
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographic keys are
>weak
>> and you have no way of knowing unless you read dmesg", and I think
>> causing boot problems is the better outcome here.
>
>Or: In one case you have a real and present problem. In the other
>case, people are talking hypotheticals.
We've been recommending that people use getrandom() for key generation since it was first added to the kernel. Github suggests there are users in the wild - there's almost certainly more cases where internal code depends on the existing semantics.
--
Matthew Garrett | [email protected]
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds <[email protected]> wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett <[email protected]>
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographic keys are
>weak
>> and you have no way of knowing unless you read dmesg", and I think
>> causing boot problems is the better outcome here.
>
>Or: In one case you have a real and present problem. In the other
>case, people are talking hypotheticals.
(resending because accidental HTML, sorry about that)
We've been recommending that people use the default getrandom() behaviour for key generation since it was merged. Github shows users, and it's likely there's cases in internal code as well.
--
Matthew Garrett | [email protected]
On Mon, Sep 16, 2019 at 4:29 PM Ahmed S. Darwish <[email protected]> wrote:
>
> Linus, in all honesty, the other case is _not_ a hypothetical .
Oh yes it is.
You're confusing "use" with "breakage".
The _use_ of getrandom(0) for key generation isn't hypothetical.
But the _breakage_ from the suggested patch that makes it time out is.
See the difference?
The thing is, to break, you have to
(a) do that key generation at boot time
(b) do it on an idle machine that doesn't have entropy
in order to basically reproduce the current boot-time hang situation
with the broken gdm, except with an actual "generate key".
Then you have to ignore the big warning too.
Linus
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 <[email protected]>
> 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