Hi Keith,
On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote:
> Jason Cooper <jason@xxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
