Date:	Mon, 16 Jun 2014 16:07:19 +0200
From:	Torsten Duwe <duwe@...e.de>
To:	Theodore Ts'o <tytso@....edu>, "H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...capital.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Arnd Bergmann <arnd@...db.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Satoru Takeuchi <satoru.takeuchi@...il.com>,
	ingo.tuchscherer@...ibm.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hans-Georg Markgraf <MGRF@...ibm.com>,
	Gerald Schaefer <gerald.schaefer@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Joe Perches <joe@...ches.com>,
	Jörn Engel <joern@...fs.org>
Subject: Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device

On Mon, Jun 16, 2014 at 07:22:07AM -0400, Theodore Ts'o wrote:
> On Mon, Jun 16, 2014 at 09:31:08AM +0200, Torsten Duwe wrote:
> > > 2)  Fixed a bug in patch #2 so that it would work correctly if the rng
> > > driver doesn't have an init function (which happens to be the case for
> > > the tpm-rng driver, which I used for my testing).
> > 
> > The whole thing stems from entropy-challenged s390. 3.12 on s390 compiles
> > and runs fine. Yields a solid 200 kB/s
> > 
> > TPM RNG is a crook ;-)
> 
> I think the word you mean is "crock" (as in "crock of sh*t"?)  :-)

Actually, I was thinking of a crutch. Makes you walk slowly, but better
than nothing. Seems I've bent the wrong tube.

> Were you referring to the typical hardware implementation in most
> TPM's, or something else?

Those are designed for the TPM's own, internal use IIRC. Their exposure
to the main computer is only a side effect.

> > With patch 03/03, it is up to the driver author to specify an entropy
> > quality, which can be overridden at boot time, or when loading
> > the module, respectively. This should be a constant hardware property.
> > It would be nice to change it at runtime; but frankly I hope that this
> > won't be neccessary.
> 
> The question of what should be the proper derating mechanism is going
> to be subject to individual administrators.  I agree that we should
> have good defaults, but for example, I'm sure the manufacturer of the
> TPM that's in my Thinkpad would try to claim that it's the Bug
> Free(tm), and try to assign it derating factor accordingly.  If the

Then the next question would be about the underlying specification.
A bug free implementation of dual-EC DRBG?

> manufacturer is supplying the device driver, it may not be a value
> that other people will agree with.  Which is why I think making it
> runtime configurable is a good thing.

Boot time configurable, I'd say. Again: this is a hardware property,
multiplied by the admin's level of confidence in the absence of backdoors.
It's easy with s390: from z/VM you can read all the guest's memory anyway.
If you use this machine, you already trust IBM.

> As another example, I assume Peter or someone else from Intel will be
> shortly submitting a hw_random driver for RDRAND on x86.  What should
> the derating factor be for that?  I suspect David Johnson's answer
> would be quite different from other people's.  And that's to be
> expected, since he has much better information that most of us have
> access to about the RDRAND implementation, and the
> likelihood/possibiliy it could have been subverted.

So let's keep it close to 0, and allow those to raise it who have confidence.

> > Maybe along with more sophisticated steering of how many bits to pick
> > from which source, if multiple are available.
> 
> Yeah, the question about what to do we have multiple hw random sources
> is something that I thought about.  Do we want to poll from more than
> one?

Of course! Choose your mix!

> Also, suppose some hw random sources require more resources ---
> battery life in particular, for mobile/laptop devices?  How do we deal
> with policy questions such as these?  Should we deal with it all, or
> just assume that userspace will dynamically enable or disable pulling
> from certain devices based on policy questions such as power
> utilization issues?

One thing after the other. What are the consumers of kernel entropy?
Mostly ASLR, I guess, and the web server / sshd accepting connections.
Those proceses starting probably eats more power than a HWRNG needs for
the appropriate random bits. We can address exceptions once they arise.

	Torsten

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists