Jason Cooper <jason@xxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
