From: Janne Blomqvist <blomqvist.janne@gmail.com>
To: Fritz Reese <fritzoreese@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>, fortran <fortran@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>,
paulkoning@comcast.net
Subject: Re: [PATCH] Use getentropy() for seeding PRNG
Date: Mon, 13 Aug 2018 20:12:00 -0000 [thread overview]
Message-ID: <CAO9iq9GpdDdQAHUROXP6uAh-Jqn2cnjayko9AsCGaxBmoX2VRA@mail.gmail.com> (raw)
In-Reply-To: <CAE4aFAk+u4ani2J2X=8YAEv4PeqW7v4eFvx5rxh4BJ9qK0J_6g@mail.gmail.com>
On Mon, Aug 13, 2018 at 5:36 PM, Fritz Reese <fritzoreese@gmail.com> wrote:
> On Fri, Aug 3, 2018 at 9:19 AM Janne Blomqvist
> <blomqvist.janne@gmail.com> wrote:
> >
> > The getentropy function, found on Linux, OpenBSD, and recently also
> > FreeBSD, can be used to get random bytes to initialize the PRNG. It
> > is similar to the traditional way of reading from /dev/urandom, but
> > being a system call rather than a special file, it doesn't suffer from
> > problems like running out of file descriptors, or failure when running
> > in a container where /dev/urandom is not available.
> >
> > Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>
> Actually, getentropy() is similar to reading from /dev/random, where
> getrandom() is similar to reading from /dev/urandom.
No, getentropy is similar to getrandom with the flags argument == 0. Which
is similar to reading /dev/urandom, except that just after boot if enough
entropy hasn't yet been gathered, it may block instead of returning some
not-quite-random data. But once it has been initialized, it will never
block again.
I agree that reading from /dev/random is overkill, but this patch isn't
doing the equivalent of that.
> Since the
> original behavior of getosrandom() is to read from /dev/urandom, I
> think it is better to use getrandom() for consistent semantics.
>
> Furthermore, getentropy() may block to achieve an appropriate degree
> of randomness, since it is intended for secure use.
The only time this might happen is just after boot, after that the entropy
never drains (in contrast to /dev/random). So unless you're planning to
write an init daemon in Fortran, this shouldn't matter.
--
Janne Blomqvist
next prev parent reply other threads:[~2018-08-13 20:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-03 13:19 Janne Blomqvist
2018-08-03 13:28 ` Jakub Jelinek
2018-08-03 14:05 ` Janne Blomqvist
2018-08-13 10:12 ` Janne Blomqvist
2018-08-13 20:07 ` Jakub Jelinek
2018-08-14 20:18 ` Rainer Orth
2018-08-14 20:29 ` Janne Blomqvist
2018-08-03 14:48 ` Paul Koning
2018-08-13 14:36 ` Fritz Reese
2018-08-13 20:12 ` Janne Blomqvist [this message]
2018-08-14 13:59 ` Fritz Reese
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=CAO9iq9GpdDdQAHUROXP6uAh-Jqn2cnjayko9AsCGaxBmoX2VRA@mail.gmail.com \
--to=blomqvist.janne@gmail.com \
--cc=fortran@gcc.gnu.org \
--cc=fritzoreese@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=paulkoning@comcast.net \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).