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

["Theodore Ts'o" <tytso@mit.edu>]

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"?)  :-)

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

If you're testing on s390, I'd appreciate it if you could give the "dev"
branch on random.git a quick try.  It has some improvements to help
deal with "entropy challenged" platforms by using the register values
to be mixed in with everything else.  This was based on some
suggestions and work by Jörn Engel.

>From my quick testing on x86 platforms, it doubles the overhead of
add_interrupt_randomness() on platforms that don't have a cycle
counter.  It still should be fairly low overhead, but it would be
great if some folks on other architectures did some testing to confirm
that the resulting overhead isn't problematic.  (Jörn wanted to mix in
all of the registers, but from my calculations, even if we only did
this once a clock tick, the overhead and resulting long tail latency
in interrupt processing time was not something I was willing to
inflict on everyone.)

Also note if you are playing with the random.git tree, there is a
fairly serious bug fix on the "for_linus_stable" branch that will be
pushed to Linus once it gets a bit more testing.

> 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
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.

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.

> > Fixing this probably means that we need to set up a formal sysfs tree
> > under /sys/kernel/hw_random.
> 
> 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?

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?

Cheers,

						- Ted