lkml.org 
[lkml]   [2016]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
Date
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-08-09 21:41    [W:0.133 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site