Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device

[Torsten Duwe <duwe@suse.de>]

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