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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Aug 2016 18:26:20 +0000
From:	Jason Cooper <jason@...edaemon.net>
To:	Keith Packard <keithp@...thp.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hwrng: core - Allow for multiple simultaneous active
 hwrng devices

Hi Keith,

On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote:
> Jason Cooper <jason@...edaemon.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.