Messages in this thread | | | From | Keith Packard <> | Subject | Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices | Date | Tue, 09 Aug 2016 12:01:13 -0700 |
| |
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] | |