lkml.org 
[lkml]   [2014]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2014-06-16 15:41    [W:2.495 / U:0.336 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site