From: "Stephan Müller" <smueller@chronox.de>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 3/8] random: trigger random_ready callback upon crng_init == 1
Date: Wed, 18 Jan 2017 18:09:14 +0100 [thread overview]
Message-ID: <1721766.rHn5SRrCCO@tauon.atsec.com> (raw)
In-Reply-To: <20170118041250.x7wszcasd4dplj3h@thunk.org>
Am Dienstag, 17. Januar 2017, 23:12:50 CET schrieb Theodore Ts'o:
Hi Theodore,
> On Tue, Dec 27, 2016 at 11:39:57PM +0100, Stephan Müller wrote:
> > The random_ready callback mechanism is intended to replicate the
> > getrandom system call behavior to in-kernel users. As the getrandom
> > system call unblocks with crng_init == 1, trigger the random_ready
> > wakeup call at the same time.
>
> It was deliberate that random_ready would only get triggered with
> crng_init==2.
>
> In general I'm assuming kernel callers really want real randomness (as
> opposed to using prandom), where as there's a lot of b.s. userspace
> users of kernel randomness (for things that really don't require
> cryptographic randomness, e.g., for salting Python dictionaries,
> systemd/udev using /dev/urandom for non-cryptographic, non-security
> applications etc.)
Users of getrandom want to ensure that they get random data from a DRNG that
is seeded, just like in-kernel users may want if they choose the callback-
approach.
I do not understand why there should be different treatment of in-kernel vs
user space callers in that respect.
(And yes, I do not want to open a discussion whether crng_init==1 can
considered as a sufficiently seeded DRNG as such discussion will lead
nowhere.)
Ciao
Stephan
next prev parent reply other threads:[~2017-01-18 17:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-27 22:38 [PATCH 0/8] random: cleanup of code after removal of nonblocking pool Stephan Müller
2016-12-27 22:39 ` [PATCH 1/8] random: remove stale maybe_reseed_primary_crng Stephan Müller
2016-12-27 22:39 ` [PATCH 2/8] random: remove stale urandom_init_wait Stephan Müller
2016-12-27 22:39 ` [PATCH 3/8] random: trigger random_ready callback upon crng_init == 1 Stephan Müller
2017-01-18 4:12 ` Theodore Ts'o
2017-01-18 17:09 ` Stephan Müller [this message]
2016-12-27 22:40 ` [PATCH 4/8] random: remove unused branch in hot code path Stephan Müller
2017-01-18 4:35 ` Theodore Ts'o
2017-04-27 11:23 ` Geert Uytterhoeven
2016-12-27 22:40 ` [PATCH 5/8] random: remove variable limit Stephan Müller
2016-12-27 22:41 ` [PATCH 6/8] random: fix comment for unused random_min_urandom_seed Stephan Müller
2016-12-27 22:41 ` [PATCH 7/8] random: remove noop function call to xfer_secondary_pool Stephan Müller
2017-01-18 16:10 ` Theodore Ts'o
2016-12-27 22:42 ` [PATCH 8/8] random: move FIPS continuous test to output functions Stephan Müller
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=1721766.rHn5SRrCCO@tauon.atsec.com \
--to=smueller@chronox.de \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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 NNTP newsgroup(s).