Messages in this thread | | | Date | Mon, 16 Jun 2014 16:07:19 +0200 | From | Torsten Duwe <> | 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
| |