From: "Theodore Ts'o" <tytso@mit.edu>
To: "Guozihua (Scott)" <guozihua@huawei.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
linux-crypto@vger.kernel.org, luto@kernel.org
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random
Date: Thu, 21 Jul 2022 07:09:32 -0400 [thread overview]
Message-ID: <Ytkz7DOfL6mFCxnI@mit.edu> (raw)
In-Reply-To: <a93995db-a738-8e4f-68f2-42d7efd3c77d@huawei.com>
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
next prev parent reply other threads:[~2022-07-21 11:09 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 7:33 Inquiry about the removal of flag O_NONBLOCK on /dev/random Guozihua (Scott)
2022-07-18 8:52 ` Guozihua (Scott)
2022-07-19 3:47 ` Eric Biggers
2022-07-19 8:06 ` Guozihua (Scott)
2022-07-19 11:01 ` Jason A. Donenfeld
2022-07-21 3:50 ` Guozihua (Scott)
2022-07-21 4:07 ` Eric Biggers
2022-07-21 6:44 ` Guozihua (Scott)
2022-07-21 6:50 ` Eric Biggers
2022-07-21 10:37 ` Jason A. Donenfeld
2022-07-21 11:30 ` Guozihua (Scott)
2022-07-26 7:43 ` Guozihua (Scott)
2022-07-26 11:08 ` Jason A. Donenfeld
2022-07-26 11:33 ` Guozihua (Scott)
2022-07-28 8:24 ` Guozihua (Scott)
2022-09-06 7:14 ` Guozihua (Scott)
2022-09-06 10:16 ` Jason A. Donenfeld
2022-09-07 13:03 ` Jason A. Donenfeld
2022-09-08 3:31 ` Guozihua (Scott)
2022-09-08 9:51 ` Jason A. Donenfeld
2022-09-08 10:40 ` Jason A. Donenfeld
2022-09-08 14:26 ` [PATCH] random: restore O_NONBLOCK support Jason A. Donenfeld
2022-09-19 10:27 ` Inquiry about the removal of flag O_NONBLOCK on /dev/random Guozihua (Scott)
2022-09-19 10:40 ` Jason A. Donenfeld
2022-09-19 10:45 ` Guozihua (Scott)
2022-07-21 11:09 ` Theodore Ts'o [this message]
2022-07-21 11:30 ` Guozihua (Scott)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ytkz7DOfL6mFCxnI@mit.edu \
--to=tytso@mit.edu \
--cc=Jason@zx2c4.com \
--cc=ebiggers@kernel.org \
--cc=guozihua@huawei.com \
--cc=linux-crypto@vger.kernel.org \
--cc=luto@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox