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
