Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1458557 > unrolled thread

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] hwrng: core - Allow for multiple simultaneous active  hwrng devices Herbert Xu <herbert@gondor.apana.org.au> - 2016-08-09 12:00 +0200
    Re: [PATCH] hwrng: core - Allow for multiple simultaneous active  hwrng devices Jason Cooper <jason@lakedaemon.net> - 2016-08-09 19:00 +0200
      Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices Keith Packard <keithp@keithp.com> - 2016-08-09 20:00 +0200
        Re: [PATCH] hwrng: core - Allow for multiple simultaneous active  hwrng devices Jason Cooper <jason@lakedaemon.net> - 2016-08-09 20:30 +0200
          Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices Keith Packard <keithp@keithp.com> - 2016-08-09 21:10 +0200
      Re: [PATCH] hwrng: core - Allow for multiple simultaneous active  hwrng devices Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2016-08-09 22:20 +0200
        Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices Keith Packard <keithp@keithp.com> - 2016-08-10 01:30 +0200

#1458557 — Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> Instead of having only one hwrng feeding /dev/random at a time, maintain
> a list of devices and cycle between them when filling the entropy pool.
> 
> Signed-off-by: Keith Packard <keithp@keithp.com>

So you're cycling RNGs even for user-space reads? That could be
problematic because not all hardware RNGs carry the maximum amount
of entropy.  It would be rather annoying to be cycling between
RNGs of different qualities.

Perhaps only cycle for the kernel hwrngd?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[toc] | [next] | [standalone]

#1458980

Hi Keith, Herbert,

On Tue, Aug 09, 2016 at 05:50:58PM +0800, Herbert Xu wrote:
> On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> > Instead of having only one hwrng feeding /dev/random at a time, maintain
> > a list of devices and cycle between them when filling the entropy pool.
> > 
> > Signed-off-by: Keith Packard <keithp@keithp.com>
> 
> So you're cycling RNGs even for user-space reads? That could be
> problematic because not all hardware RNGs carry the maximum amount
> of entropy.  It would be rather annoying to be cycling between
> RNGs of different qualities.
> 
> Perhaps only cycle for the kernel hwrngd?

Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
sysfs interface for per device quality, rate, and enabled attributes.
e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}

/dev/hwrng could pull from the one with the highest quality, or user
specified for backwards compatibility.

thx,

Jason.

[toc] | [prev] | [next] | [standalone]

#1459038 — Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Multipart message — attachments visible in raw view] — view raw

Jason Cooper <jason@lakedaemon.net> writes:

> Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}

I was interested in the data being provided for /dev/random; that seems
like the most important interface to me.  But, exposing all of the
devices using consistent names does seem like a useful idea at some
level.

> /dev/hwrng could pull from the one with the highest quality, or user
> specified for backwards compatibility.

I like the notion of using all of them in turn; if one of them turns out
to be broken, you're still stirring in data from the others. After all,
the quality metric is provided by the device, we aren't doing any
analysis on the data to determine it independently.

-- 
-keith

[toc] | [prev] | [next] | [standalone]

#1459049

Hi Keith,

On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> > Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
> > sysfs interface for per device quality, rate, and enabled attributes.
> > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
> 
> I was interested in the data being provided for /dev/random; that seems
> like the most important interface to me.

Me too, agreed.

> But, exposing all of the devices using consistent names does seem like
> a useful idea at some level.

On another thread, regarding the ath9k-rng (actually just the adc
registers), Henrique asked about per-source knobs.  My suggestion
follows from that.

> > /dev/hwrng could pull from the one with the highest quality, or user
> > specified for backwards compatibility.
> 
> I like the notion of using all of them in turn; if one of them turns out
> to be broken, you're still stirring in data from the others. After all,
> the quality metric is provided by the device, we aren't doing any
> analysis on the data to determine it independently.

Sure, but /dev/hwrng is a user interface.  Typically to rngd, but not
necessarily.  We need to make sure it's behavior is consistent with
existing expectations.

We shouldn't attach first-probed to /dev/hwrng, because that may not be
what the user is expecting.  If I bought a raw entropy source, and knew
nothing of the proposed multi-source interfaces, I'd expect the USB
dongle to be attached to /dev/hwrng.  Despite the fact that my pcie wifi
card was probed first and has adc registers providing an entropy source.

I'm not sure how we ensure that.  Perhaps an 'environmental' flag in the
hw_random source attributes?  Or a 'not-designed-to-be-an-rng' flag? :)
Maybe those would be /dev/envrng[0-9]...

thx,

Jason.

[toc] | [prev] | [next] | [standalone]

#1459066 — Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Multipart message — attachments visible in raw view] — view raw

Jason Cooper <jason@lakedaemon.net> writes:

> On another thread, regarding the ath9k-rng (actually just the adc
> registers), Henrique asked about per-source knobs.  My suggestion
> follows from that.

I'd do that with the source-specific driver instead of attempting to
route controls through hwrng. Anything else seems like 'ioctl' to me.

> Sure, but /dev/hwrng is a user interface.  Typically to rngd, but not
> necessarily.  We need to make sure it's behavior is consistent with
> existing expectations.

Hrm. Maybe /dev/hwrng should use a different policy than how we feed
/dev/random -- we could use the existing behaviour for /dev/hwrng, but
use a round-robin for /dev/random. That way, the latest device would
always end up in /dev/hwrng (unless configured otherwise), and we'd
still use all of the available sources to help stir the kernel entropy
pool.

> We shouldn't attach first-probed to /dev/hwrng, because that may not be
> what the user is expecting.  If I bought a raw entropy source, and knew
> nothing of the proposed multi-source interfaces, I'd expect the USB
> dongle to be attached to /dev/hwrng.  Despite the fact that my pcie wifi
> card was probed first and has adc registers providing an entropy source.

That seems like a fragile interface as it depends on discovery order,
but it is what we have currently.

The chaoskey driver also exposes it's own device; that provides a simple
way to ensure that the application is getting bits from the desired
entropy source.

> I'm not sure how we ensure that.  Perhaps an 'environmental' flag in the
> hw_random source attributes?  Or a 'not-designed-to-be-an-rng' flag? :)
> Maybe those would be /dev/envrng[0-9]...

Or some set of query ioctls on /dev/hwrng[0-9]+ that would provide
information about the capabilities of the underlying device.

There are lots of things we could do, I guess the question I have is how
much of this would applications actually use effectively? You're
probably right that /dev/hwrng should point at a single source and not
change though; otherwise figuring out what the quality of the bits
you're getting isn't possible.x

-- 
-keith

[toc] | [prev] | [next] | [standalone]

#1459096

On Tue, 09 Aug 2016, Jason Cooper wrote:
> Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}

IMHO, this is mightly annoying to use from inside a rngd-like utility in
a race-free, safe way.  It looks to me that ioctl() would be a much
better interface for everything but the "enabled" functionality (which
should be reported to the rngd-like utility as open() on the real device
failing with, e.g., ENXIO, when that source is disabled).

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#1459191 — Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Multipart message — attachments visible in raw view] — view raw

Henrique de Moraes Holschuh <hmh@hmh.eng.br> writes:

> IMHO, this is mightly annoying to use from inside a rngd-like utility in
> a race-free, safe way.  It looks to me that ioctl() would be a much
> better interface for everything but the "enabled" functionality (which
> should be reported to the rngd-like utility as open() on the real device
> failing with, e.g., ENXIO, when that source is disabled).

What information does an rngd-like program actually want? All I can
think that it would need is the stream of random data. I guess some
estimate of the entropy available would be nice, but surely it would
want to verify that in any case.

-- 
-keith

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web