[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140616140719.GA1744@suse.de>
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