public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).