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, 09 Aug 2016 12:01:13 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Jason Cooper <jason@...edaemon.net>
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

Jason Cooper <jason@...edaemon.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

Download attachment "signature.asc" of type "application/pgp-signature" (811 bytes)