public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Amit Shah <amit.shah@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Jason Cooper <jason@lakedaemon.net>,
	LKML <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"# 3.4.x" <stable@vger.kernel.org>
Subject: Re: [PATCH 1/2 v2] hwrng: Allow drivers to disable reading during probe
Date: Wed, 2 Jul 2014 21:32:23 +0530	[thread overview]
Message-ID: <20140702160223.GC12962@grmbl.mre> (raw)
In-Reply-To: <CAGXu5j+sbiK9zdkwWh_MD1fk4aFs-Na4ZO=3tRosGtqjFvWnDg@mail.gmail.com>

On (Wed) 02 Jul 2014 [08:11:30], Kees Cook wrote:
> On Wed, Jul 2, 2014 at 6:41 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote:
> >> Hi Jason,
> >>
> >> On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote:
> >> > Commit d9e7972619334 "hwrng: add randomness to system from rng sources"
> >> > added a call to rng_get_data() from the hwrng_register() function.
> >> > However, some rng devices need initialization before data can be read
> >> > from them.
> >> >
> >> > Also, the virtio-rng device does not behave properly when this call is
> >> > made in its probe() routine - the virtio core sets the DRIVER_OK status
> >> > bit only on a successful probe, which means the host ignores all
> >> > communication from the guest, and the guest insmod or boot process just
> >> > sits there doing nothing.
> >> >
> >> > [ jac: Modify the API to allow drivers to disable reading at probe, new
> >> > patch, copied Amit's commit message. ]
> >> >
> >> > CC: Kees Cook <keescook@chromium.org>
> >> > CC: Jason Cooper <jason@lakedaemon.net>
> >> > CC: Herbert Xu <herbert@gondor.apana.org.au>
> >> > CC: <stable@vger.kernel.org> # v3.15+
> >> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> >> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> >> > ---
> >> >  drivers/char/hw_random/core.c | 8 +++++---
> >> >  include/linux/hw_random.h     | 4 ++++
> >> >  2 files changed, 9 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> >> > index 334601cc81cf..b7b6c48ca682 100644
> >> > --- a/drivers/char/hw_random/core.c
> >> > +++ b/drivers/char/hw_random/core.c
> >> > @@ -347,9 +347,11 @@ int hwrng_register(struct hwrng *rng)
> >> >     INIT_LIST_HEAD(&rng->list);
> >> >     list_add_tail(&rng->list, &rng_list);
> >> >
> >> > -   bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
> >> > -   if (bytes_read > 0)
> >> > -           add_device_randomness(bytes, bytes_read);
> >> > +   if (!(rng->flags & HWRNG_NO_READ_AT_PROBE)) {
> >> > +           bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
> >> > +           if (bytes_read > 0)
> >> > +                   add_device_randomness(bytes, bytes_read);
> >> > +   }
> >>
> >> But this has the inverse problem: if there are two hwrngs in the
> >> system, one will be initialized and probed.  The other will not be
> >> initialized, but still be probed.
> >
> > That's a problem outside the scope of this patch.  You're basically
> > saying the ->init() should be called unconditionally for each hwrng.  If
> > that's what driver authors assumed, that's not what is happening if
> > there is more than one driver in the system.
> 
> My intent with the patch was to get randomness added when a hwrng was
> available. Perhaps instead of skipping this call, it can be done
> either during probe (for devices that support it or lack an init
> function), or done after initialization?

I'll also look at just going ahead with ->init() in the hwrng_register
function itself, that's in line with the spirit of your patch.

However, that may lead to unwelcome problems.  The other approach is
to call rng_get_data() in hwrng_init().

> > I think you should be changing the code a few lines up to make sure
> > hwrng_init() is called once for each driver.
> 
> Is that really how it should work? I'd be for the "always-init"
> approach since it gains us access to the entropy, but I have to play
> devil's advocate: would one expect "probe" to just probe, not
> initialize? That seems more like a function of enabling the device.

There are some other considerations: I found this problem while
looking at other things: especially that the hwrng core doesn't take a
reference on the driver that's the current_rng.  That has to be
fixed.  If we always call ->init(), we'll have to cleanup and possibly
take a reference.  I'll look at this more closely in a bit.

		Amit

  reply	other threads:[~2014-07-02 16:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-02 10:28 [PATCH 0/2] hwrng: don't fetch data before device init Amit Shah
2014-07-02 10:28 ` [PATCH 1/2] hwrng: don't fetch rng from sources without init Amit Shah
2014-07-02 11:58   ` Jason Cooper
2014-07-02 12:11     ` Amit Shah
2014-07-02 12:14       ` Jason Cooper
2014-07-02 10:28 ` [PATCH 2/2] virtio: rng: introduce an init fn for hwrng core Amit Shah
2014-07-02 13:00 ` [PATCH 1/2 v2] hwrng: Allow drivers to disable reading during probe Jason Cooper
2014-07-02 13:00   ` [PATCH 2/2 v2] hwrng: virtio: " Jason Cooper
2014-07-02 13:26   ` [PATCH 1/2 v2] hwrng: Allow drivers to " Amit Shah
2014-07-02 13:41     ` Jason Cooper
2014-07-02 15:11       ` Kees Cook
2014-07-02 16:02         ` Amit Shah [this message]
2014-07-02 15:58       ` Amit Shah

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=20140702160223.GC12962@grmbl.mre \
    --to=amit.shah@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jason@lakedaemon.net \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.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