2022-07-14 07:44:59

by Guozihua (Scott)

[permalink] [raw]
Subject: Inquiry about the removal of flag O_NONBLOCK on /dev/random

Hi Community,

Recently we noticed the removal of flag O_NONBLOCK on /dev/random by
commit 30c08efec888 ("random: make /dev/random be almost like
/dev/urandom"), it seems that some of the open_source packages e.g.
random_get_fd() of util-linux and __getrandom() of glibc. The man page
for random() is not updated either.

Would anyone please kindly provide some background knowledge of this
flag and it's removal? Thanks!

--
Best
GUO Zihua


2022-07-18 08:58:06

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/14 15:33, Guozihua (Scott) wrote:
> Hi Community,
>
> Recently we noticed the removal of flag O_NONBLOCK on /dev/random by
> commit 30c08efec888 ("random: make /dev/random be almost like
> /dev/urandom"), it seems that some of the open_source packages e.g.
> random_get_fd() of util-linux and __getrandom() of glibc. The man page
> for random() is not updated either.

Correction: I mean various open source packages are still using
O_NONBLOCK flag while accessing /dev/random
>
> Would anyone please kindly provide some background knowledge of this
> flag and it's removal? Thanks!
>
--
Best
GUO Zihua

2022-07-19 03:49:05

by Eric Biggers

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On Mon, Jul 18, 2022 at 04:52:59PM +0800, Guozihua (Scott) wrote:
> On 2022/7/14 15:33, Guozihua (Scott) wrote:
> > Hi Community,
> >
> > Recently we noticed the removal of flag O_NONBLOCK on /dev/random by
> > commit 30c08efec888 ("random: make /dev/random be almost like
> > /dev/urandom"), it seems that some of the open_source packages e.g.
> > random_get_fd() of util-linux and __getrandom() of glibc. The man page
> > for random() is not updated either.
>
> Correction: I mean various open source packages are still using O_NONBLOCK
> flag while accessing /dev/random
> >
> > Would anyone please kindly provide some background knowledge of this
> > flag and it's removal? Thanks!
> >

This was changed a while ago, in v5.6. /dev/random no longer recognizes
O_NONBLOCK because it no longer blocks, except before the entropy pool has been
initialized.

(I don't know why O_NONBLOCK stopped being recognized *before* the entropy pool
has been initialized; it's either an oversight, or it was decided it doesn't
matter. Probably the latter, since I can't think of a real use case for using
O_NONBLOCK on /dev/random.)

The random(4) man page is indeed in need of an update, not just for this reason
but for some other reasons too.

The util-linux code which you mentioned is opening /dev/random with O_NONBLOCK
if opening /dev/urandom fails, which is pretty much pointless. Perhaps the
author thought that /dev/random with O_NONBLOCK is equivalent to /dev/urandom
(it's not). The glibc code, if you mean sysdeps/mach/hurd/getrandom.c, is
actually code written for GNU Hurd, not for Linux, so it's not relevant.

- Eric

2022-07-19 08:12:40

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

> (I don't know why O_NONBLOCK stopped being recognized *before* the entropy pool
> has been initialized; it's either an oversight, or it was decided it doesn't
> matter. Probably the latter, since I can't think of a real use case for using
> O_NONBLOCK on /dev/random.)

Does this mean that we expect all users of /dev/random to block until it
is initialized?

--
Best
GUO Zihua

2022-07-19 11:12:18

by Jason A. Donenfeld

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

Hi,

On Thu, Jul 14, 2022 at 03:33:47PM +0800, Guozihua (Scott) wrote:
> Recently we noticed the removal of flag O_NONBLOCK on /dev/random by
> commit 30c08efec888 ("random: make /dev/random be almost like
> /dev/urandom"), it seems that some of the open_source packages e.g.
> random_get_fd() of util-linux and __getrandom() of glibc. The man page
> for random() is not updated either.
>
> Would anyone please kindly provide some background knowledge of this
> flag and it's removal? Thanks!

I didn't write that code, but I assume it was done this way because it
doesn't really matter that much now, as /dev/random never blocks after
the RNG is seeded. And now a days, the RNG gets seeded with jitter
fairly quickly as a last resort, so almost nobody waits a long time.

Looking at the two examples you mentioned, the one in util-linux does
that if /dev/urandom fails, which means it's mostly unused code, and the
one in glibc is for GNU Hurd, not Linux. I did a global code search and
found a bunch of other instances pretty similar to the util-linux case,
where /dev/random in O_NONBLOCK mode is used as a fallback to
/dev/urandom, which means it's basically never used. (Amusingly one such
user of this pattern is Ted's pwgen code from way back at the turn of
the millennium.)

All together, I couldn't really find anywhere that the removal of
O_NONBLOCK semantics would actually pose a problem for, especially since
/dev/random doesn't block at all after being initialized. So I'm
slightly leaning toward the "doesn't matter, do nothing" course of
action.

But on the other hand, you did somehow notice this, so that's important
perhaps. How did you run into it? *Does* it actually pose a problem? Or
was this a mostly theoretical finding from perusing source code?
Something like the below diff would probably work and isn't too
invasive, but I think I'd prefer to leave it be unless this really did
break some userspace of yours. So please let me know.

Regards,
Jason

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 70d8d1d7e2d7..6f232ac258bf 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1347,6 +1347,10 @@ static ssize_t random_read_iter(struct kiocb *kiocb, struct iov_iter *iter)
{
int ret;

+ if (!crng_ready() &&
+ ((kiocb->ki_flags & IOCB_NOWAIT) || (kiocb->ki_filp->f_flags & O_NONBLOCK)))
+ return -EAGAIN;
+
ret = wait_for_random_bytes();
if (ret != 0)
return ret;

2022-07-21 03:54:36

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/19 19:01, Jason A. Donenfeld wrote:
> Hi,
>
> On Thu, Jul 14, 2022 at 03:33:47PM +0800, Guozihua (Scott) wrote:
>> Recently we noticed the removal of flag O_NONBLOCK on /dev/random by
>> commit 30c08efec888 ("random: make /dev/random be almost like
>> /dev/urandom"), it seems that some of the open_source packages e.g.
>> random_get_fd() of util-linux and __getrandom() of glibc. The man page
>> for random() is not updated either.
>>
>> Would anyone please kindly provide some background knowledge of this
>> flag and it's removal? Thanks!
>
> I didn't write that code, but I assume it was done this way because it
> doesn't really matter that much now, as /dev/random never blocks after
> the RNG is seeded. And now a days, the RNG gets seeded with jitter
> fairly quickly as a last resort, so almost nobody waits a long time.
>
> Looking at the two examples you mentioned, the one in util-linux does
> that if /dev/urandom fails, which means it's mostly unused code, and the
> one in glibc is for GNU Hurd, not Linux. I did a global code search and
> found a bunch of other instances pretty similar to the util-linux case,
> where /dev/random in O_NONBLOCK mode is used as a fallback to
> /dev/urandom, which means it's basically never used. (Amusingly one such
> user of this pattern is Ted's pwgen code from way back at the turn of
> the millennium.)
>
> All together, I couldn't really find anywhere that the removal of
> O_NONBLOCK semantics would actually pose a problem for, especially since
> /dev/random doesn't block at all after being initialized. So I'm
> slightly leaning toward the "doesn't matter, do nothing" course of
> action.
>
> But on the other hand, you did somehow notice this, so that's important
> perhaps. How did you run into it? *Does* it actually pose a problem? Or
> was this a mostly theoretical finding from perusing source code?
> Something like the below diff would probably work and isn't too
> invasive, but I think I'd prefer to leave it be unless this really did
> break some userspace of yours. So please let me know.
>
> Regards,
> Jason
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 70d8d1d7e2d7..6f232ac258bf 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1347,6 +1347,10 @@ static ssize_t random_read_iter(struct kiocb *kiocb, struct iov_iter *iter)
> {
> int ret;
>
> + if (!crng_ready() &&
> + ((kiocb->ki_flags & IOCB_NOWAIT) || (kiocb->ki_filp->f_flags & O_NONBLOCK)))
> + return -EAGAIN;
> +
> ret = wait_for_random_bytes();
> if (ret != 0)
> return ret;
>
> .

Hi Jason, Thanks for the respond.

The reason this comes to me is that we have an environment that is super
clean with very limited random events and with very limited random
hardware access. It would take up to 80 minutes before /dev/random is
fully initialized. I think it would be great if we can restore the
O_NONBLOCK flag.

Would you mind merge this change into mainstream or may I have the honor?

--
Best
GUO Zihua

2022-07-21 04:10:59

by Eric Biggers

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On Thu, Jul 21, 2022 at 11:50:27AM +0800, Guozihua (Scott) wrote:
> On 2022/7/19 19:01, Jason A. Donenfeld wrote:
> > Hi,
> >
> > On Thu, Jul 14, 2022 at 03:33:47PM +0800, Guozihua (Scott) wrote:
> > > Recently we noticed the removal of flag O_NONBLOCK on /dev/random by
> > > commit 30c08efec888 ("random: make /dev/random be almost like
> > > /dev/urandom"), it seems that some of the open_source packages e.g.
> > > random_get_fd() of util-linux and __getrandom() of glibc. The man page
> > > for random() is not updated either.
> > >
> > > Would anyone please kindly provide some background knowledge of this
> > > flag and it's removal? Thanks!
> >
> > I didn't write that code, but I assume it was done this way because it
> > doesn't really matter that much now, as /dev/random never blocks after
> > the RNG is seeded. And now a days, the RNG gets seeded with jitter
> > fairly quickly as a last resort, so almost nobody waits a long time.
> >
> > Looking at the two examples you mentioned, the one in util-linux does
> > that if /dev/urandom fails, which means it's mostly unused code, and the
> > one in glibc is for GNU Hurd, not Linux. I did a global code search and
> > found a bunch of other instances pretty similar to the util-linux case,
> > where /dev/random in O_NONBLOCK mode is used as a fallback to
> > /dev/urandom, which means it's basically never used. (Amusingly one such
> > user of this pattern is Ted's pwgen code from way back at the turn of
> > the millennium.)
> >
> > All together, I couldn't really find anywhere that the removal of
> > O_NONBLOCK semantics would actually pose a problem for, especially since
> > /dev/random doesn't block at all after being initialized. So I'm
> > slightly leaning toward the "doesn't matter, do nothing" course of
> > action.
> >
> > But on the other hand, you did somehow notice this, so that's important
> > perhaps. How did you run into it? *Does* it actually pose a problem? Or
> > was this a mostly theoretical finding from perusing source code?
> > Something like the below diff would probably work and isn't too
> > invasive, but I think I'd prefer to leave it be unless this really did
> > break some userspace of yours. So please let me know.
> >
> > Regards,
> > Jason
> >
> > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > index 70d8d1d7e2d7..6f232ac258bf 100644
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> > @@ -1347,6 +1347,10 @@ static ssize_t random_read_iter(struct kiocb *kiocb, struct iov_iter *iter)
> > {
> > int ret;
> > + if (!crng_ready() &&
> > + ((kiocb->ki_flags & IOCB_NOWAIT) || (kiocb->ki_filp->f_flags & O_NONBLOCK)))
> > + return -EAGAIN;
> > +
> > ret = wait_for_random_bytes();
> > if (ret != 0)
> > return ret;
> >
> > .
>
> Hi Jason, Thanks for the respond.
>
> The reason this comes to me is that we have an environment that is super
> clean with very limited random events and with very limited random hardware
> access. It would take up to 80 minutes before /dev/random is fully
> initialized. I think it would be great if we can restore the O_NONBLOCK
> flag.
>
> Would you mind merge this change into mainstream or may I have the honor?
>

Can you elaborate on how this change would actually solve a problem for you? Do
you actually have a program that is using /dev/random with O_NONBLOCK, and that
handles the EAGAIN error correctly? Just because you're seeing a program wait
for the RNG to be initialized doesn't necessarily mean that this change would
make a difference, as the program could just be reading from /dev/random without
O_NONBLOCK or calling getrandom() without GRND_NONBLOCK. The behavior of those
(more common) cases would be unchanged by Jason's proposed change.

- Eric

2022-07-21 06:46:48

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/21 12:07, Eric Biggers wrote:
> On Thu, Jul 21, 2022 at 11:50:27AM +0800, Guozihua (Scott) wrote:
>> On 2022/7/19 19:01, Jason A. Donenfeld wrote:
>>> Hi,
>>>
>>> On Thu, Jul 14, 2022 at 03:33:47PM +0800, Guozihua (Scott) wrote:
>>>> Recently we noticed the removal of flag O_NONBLOCK on /dev/random by
>>>> commit 30c08efec888 ("random: make /dev/random be almost like
>>>> /dev/urandom"), it seems that some of the open_source packages e.g.
>>>> random_get_fd() of util-linux and __getrandom() of glibc. The man page
>>>> for random() is not updated either.
>>>>
>>>> Would anyone please kindly provide some background knowledge of this
>>>> flag and it's removal? Thanks!
>>>
>>> I didn't write that code, but I assume it was done this way because it
>>> doesn't really matter that much now, as /dev/random never blocks after
>>> the RNG is seeded. And now a days, the RNG gets seeded with jitter
>>> fairly quickly as a last resort, so almost nobody waits a long time.
>>>
>>> Looking at the two examples you mentioned, the one in util-linux does
>>> that if /dev/urandom fails, which means it's mostly unused code, and the
>>> one in glibc is for GNU Hurd, not Linux. I did a global code search and
>>> found a bunch of other instances pretty similar to the util-linux case,
>>> where /dev/random in O_NONBLOCK mode is used as a fallback to
>>> /dev/urandom, which means it's basically never used. (Amusingly one such
>>> user of this pattern is Ted's pwgen code from way back at the turn of
>>> the millennium.)
>>>
>>> All together, I couldn't really find anywhere that the removal of
>>> O_NONBLOCK semantics would actually pose a problem for, especially since
>>> /dev/random doesn't block at all after being initialized. So I'm
>>> slightly leaning toward the "doesn't matter, do nothing" course of
>>> action.
>>>
>>> But on the other hand, you did somehow notice this, so that's important
>>> perhaps. How did you run into it? *Does* it actually pose a problem? Or
>>> was this a mostly theoretical finding from perusing source code?
>>> Something like the below diff would probably work and isn't too
>>> invasive, but I think I'd prefer to leave it be unless this really did
>>> break some userspace of yours. So please let me know.
>>>
>>> Regards,
>>> Jason
>>>
>>> diff --git a/drivers/char/random.c b/drivers/char/random.c
>>> index 70d8d1d7e2d7..6f232ac258bf 100644
>>> --- a/drivers/char/random.c
>>> +++ b/drivers/char/random.c
>>> @@ -1347,6 +1347,10 @@ static ssize_t random_read_iter(struct kiocb *kiocb, struct iov_iter *iter)
>>> {
>>> int ret;
>>> + if (!crng_ready() &&
>>> + ((kiocb->ki_flags & IOCB_NOWAIT) || (kiocb->ki_filp->f_flags & O_NONBLOCK)))
>>> + return -EAGAIN;
>>> +
>>> ret = wait_for_random_bytes();
>>> if (ret != 0)
>>> return ret;
>>>
>>> .
>>
>> Hi Jason, Thanks for the respond.
>>
>> The reason this comes to me is that we have an environment that is super
>> clean with very limited random events and with very limited random hardware
>> access. It would take up to 80 minutes before /dev/random is fully
>> initialized. I think it would be great if we can restore the O_NONBLOCK
>> flag.
>>
>> Would you mind merge this change into mainstream or may I have the honor?
>>
>
> Can you elaborate on how this change would actually solve a problem for you? Do
> you actually have a program that is using /dev/random with O_NONBLOCK, and that
> handles the EAGAIN error correctly? Just because you're seeing a program wait
> for the RNG to be initialized doesn't necessarily mean that this change would
> make a difference, as the program could just be reading from /dev/random without
> O_NONBLOCK or calling getrandom() without GRND_NONBLOCK. The behavior of those
> (more common) cases would be unchanged by Jason's proposed change.
>
> - Eric
> .

Hi Eric

We have a userspace program that starts pretty early in the boot process
and it tries to fetch random bits from /dev/random with O_NONBLOCK, if
that returns -EAGAIN, it turns to /dev/urandom. Is this a correct
handling of -EAGAIN? Or this is not one of the intended use case of
O_NONBLOCK?

--
Best
GUO Zihua

2022-07-21 06:51:41

by Eric Biggers

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On Thu, Jul 21, 2022 at 02:44:54PM +0800, Guozihua (Scott) wrote:
>
> Hi Eric
>
> We have a userspace program that starts pretty early in the boot process and
> it tries to fetch random bits from /dev/random with O_NONBLOCK, if that
> returns -EAGAIN, it turns to /dev/urandom. Is this a correct handling of
> -EAGAIN? Or this is not one of the intended use case of O_NONBLOCK?

That doesn't make any sense; you should just use /dev/urandom unconditionally.

- Eric

2022-07-21 10:41:53

by Jason A. Donenfeld

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

Hi Guozihua,

On Wed, Jul 20, 2022 at 11:50:46PM -0700, Eric Biggers wrote:
> On Thu, Jul 21, 2022 at 02:44:54PM +0800, Guozihua (Scott) wrote:
> >
> > Hi Eric
> >
> > We have a userspace program that starts pretty early in the boot process and
> > it tries to fetch random bits from /dev/random with O_NONBLOCK, if that
> > returns -EAGAIN, it turns to /dev/urandom. Is this a correct handling of
> > -EAGAIN? Or this is not one of the intended use case of O_NONBLOCK?
>
> That doesn't make any sense; you should just use /dev/urandom unconditionally.

What Eric said: this flow doesn't really make sense. Why not use
/dev/urandom unconditionally or getrandom(GRND_INSECURE)?

But also I have to wonder: you wrote '-EAGAIN' but usually userspace
checks errno==EAGAIN, a positive value. That makes me wonder whether you
wrote your email with your code is open. So I just wanted to triple
check that what you've described is actually what the code is doing,
just in case there's some ambiguity.

I'm just trying to find out what this code is and where it is to assess
whether we change the userspace behavior again, given that this has been
sitting for several years now.

Jason

2022-07-21 11:31:03

by Theodore Ts'o

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On Thu, Jul 21, 2022 at 02:44:54PM +0800, Guozihua (Scott) wrote:
>
> We have a userspace program that starts pretty early in the boot process and
> it tries to fetch random bits from /dev/random with O_NONBLOCK, if that
> returns -EAGAIN, it turns to /dev/urandom. Is this a correct handling of
> -EAGAIN? Or this is not one of the intended use case of O_NONBLOCK?

In addition to the good points which Eric and Jason have raised, the
other thing I would ask you is ***why*** is your userspace program
trying to fetch random bits early in the boot process? Is it, say,
trying to generate a cryptographic key which is security critical. If
so, then DON'T DO THAT.

There have been plenty of really embarrassing security problems caused
by consumer grade products who generate a public/private key pair
within seconds of the customer taking the product out of the box, and
plugging it into the wall for the first time. At which point,
hilarity ensues, unless the box is life- or mission- critical, in
which case tragedy ensues....

Is it possible to move the userspace program so it's not being started
early in the boot process? What is it doing, and why does it need
random data in the first place?

- Ted

2022-07-21 11:40:23

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/21 19:09, Theodore Ts'o wrote:
> On Thu, Jul 21, 2022 at 02:44:54PM +0800, Guozihua (Scott) wrote:
> >
>> We have a userspace program that starts pretty early in the boot process and
>> it tries to fetch random bits from /dev/random with O_NONBLOCK, if that
>> returns -EAGAIN, it turns to /dev/urandom. Is this a correct handling of
>> -EAGAIN? Or this is not one of the intended use case of O_NONBLOCK?
>
> In addition to the good points which Eric and Jason have raised, the
> other thing I would ask you is ***why*** is your userspace program
> trying to fetch random bits early in the boot process? Is it, say,
> trying to generate a cryptographic key which is security critical. If
> so, then DON'T DO THAT.
>
> There have been plenty of really embarrassing security problems caused
> by consumer grade products who generate a public/private key pair
> within seconds of the customer taking the product out of the box, and
> plugging it into the wall for the first time. At which point,
> hilarity ensues, unless the box is life- or mission- critical, in
> which case tragedy ensues....
>
> Is it possible to move the userspace program so it's not being started
> early in the boot process? What is it doing, and why does it need
> random data in the first place?
>
> - Ted
> .

Hi Ted,

Thanks for the comment. The code is not written by me, but I think you
made a good point here and I'll definitely bring this up to the author.

--
Best
GUO Zihua

2022-07-21 11:44:37

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/21 18:37, Jason A. Donenfeld wrote:
> Hi Guozihua,
>
> On Wed, Jul 20, 2022 at 11:50:46PM -0700, Eric Biggers wrote:
>> On Thu, Jul 21, 2022 at 02:44:54PM +0800, Guozihua (Scott) wrote:
>>
>> That doesn't make any sense; you should just use /dev/urandom unconditionally.
>
> What Eric said: this flow doesn't really make sense. Why not use
> /dev/urandom unconditionally or getrandom(GRND_INSECURE)?
>
> But also I have to wonder: you wrote '-EAGAIN' but usually userspace
> checks errno==EAGAIN, a positive value. That makes me wonder whether you
> wrote your email with your code is open. So I just wanted to triple
> check that what you've described is actually what the code is doing,
> just in case there's some ambiguity.
>
> I'm just trying to find out what this code is and where it is to assess
> whether we change the userspace behavior again, given that this has been
> sitting for several years now.
>
> Jason
> .

Hi Jason and Eric.

To clarify, the code in question is not written by me and I did not see
the code myself, the code is from another team. We discovered this
change during the test when we try to run our userspace program on a
newer version kernel, and it blocks for a long time during the boot
process. It seems that the author use the -EAGAIN error code as an
indication that /dev/random is not ready and they implemented a "best
effort" mechanism in terms of getting random data.

Honestly speaking I don't know what they are using those random data
for, and I am trying to get some background knowledge for this flag and
the change, maybe figure out whether that team is using the flag as
intended, and bring this up with them.

--
Best
GUO Zihua

2022-07-26 07:47:19

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/21 18:37, Jason A. Donenfeld wrote:
> Hi Guozihua,
>
> On Wed, Jul 20, 2022 at 11:50:46PM -0700, Eric Biggers wrote:
>> On Thu, Jul 21, 2022 at 02:44:54PM +0800, Guozihua (Scott) wrote:
>>>
>>> Hi Eric
>>>
>>> We have a userspace program that starts pretty early in the boot process and
>>> it tries to fetch random bits from /dev/random with O_NONBLOCK, if that
>>> returns -EAGAIN, it turns to /dev/urandom. Is this a correct handling of
>>> -EAGAIN? Or this is not one of the intended use case of O_NONBLOCK?
>>
>> That doesn't make any sense; you should just use /dev/urandom unconditionally.
>
> What Eric said: this flow doesn't really make sense. Why not use
> /dev/urandom unconditionally or getrandom(GRND_INSECURE)?
>
> But also I have to wonder: you wrote '-EAGAIN' but usually userspace
> checks errno==EAGAIN, a positive value. That makes me wonder whether you
> wrote your email with your code is open. So I just wanted to triple
> check that what you've described is actually what the code is doing,
> just in case there's some ambiguity.
>
> I'm just trying to find out what this code is and where it is to assess
> whether we change the userspace behavior again, given that this has been
> sitting for several years now.
>
> Jason
> .

Hi Jason, Eric and Theodore,

Thanks for all the comments on this inquiry. Does the community has any
channel to publishes changes like these? And will the man pages get
updated? If so, are there any time frame?

--
Best
GUO Zihua

2022-07-26 11:12:15

by Jason A. Donenfeld

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

Hi,

On Tue, Jul 26, 2022 at 03:43:31PM +0800, Guozihua (Scott) wrote:
> Thanks for all the comments on this inquiry. Does the community has any
> channel to publishes changes like these? And will the man pages get
> updated? If so, are there any time frame?

I was under the impression you were ultimately okay with the status quo.
Have I misunderstood you?

Thanks,
Jason

2022-07-26 11:36:38

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/26 19:08, Jason A. Donenfeld wrote:
> Hi,
>
> On Tue, Jul 26, 2022 at 03:43:31PM +0800, Guozihua (Scott) wrote:
>> Thanks for all the comments on this inquiry. Does the community has any
>> channel to publishes changes like these? And will the man pages get
>> updated? If so, are there any time frame?
>
> I was under the impression you were ultimately okay with the status quo.
> Have I misunderstood you?
>
> Thanks,
> Jason
> .

Hi Jason.

To clarify, I does not have any issue with this change. I asked here
only because I would like some background knowledge on this flag, to
ensure I am on the same page as the community regarding this flag and
the change. And it seems that I understands it correctly.

However I do think it's a good idea to update the document soon to avoid
any misunderstanding in the future.

--
Best
GUO Zihua

2022-07-28 08:35:50

by Guozihua (Scott)

[permalink] [raw]
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random

On 2022/7/26 19:33, Guozihua (Scott) wrote:
> On 2022/7/26 19:08, Jason A. Donenfeld wrote:
>> Hi,
>>
>> On Tue, Jul 26, 2022 at 03:43:31PM +0800, Guozihua (Scott) wrote:
>>> Thanks for all the comments on this inquiry. Does the community has any
>>> channel to publishes changes like these? And will the man pages get
>>> updated? If so, are there any time frame?
>>
>> I was under the impression you were ultimately okay with the status quo.
>> Have I misunderstood you?
>>
>> Thanks,
>> Jason
>> .
>
> Hi Jason.
>
> To clarify, I does not have any issue with this change. I asked here
> only because I would like some background knowledge on this flag, to
> ensure I am on the same page as the community regarding this flag and
> the change. And it seems that I understands it correctly.
>
> However I do think it's a good idea to update the document soon to avoid
> any misunderstanding in the future.
>

Our colleague suggests that we should inform users clearly about the
change on the flag by returning -EINVAL when /dev/random gets this flag
during boot process. Otherwise programs might silently block for a long
time, causing other issues. Do you think this is a good way to prevent
similar issues on this flag?

--
Best
GUO Zihua