Thread (16 messages) flat view 16 messages, 5 authors, 2016-09-27

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

From: Jason Cooper <hidden>
Date: 2016-08-14 18:11:30
Also in: linux-wireless, lkml

Hey Ted,

On Wed, Aug 10, 2016 at 07:44:25PM -0400, Theodore Ts'o wrote:
On Tue, Aug 09, 2016 at 02:04:44PM +0000, Jason Cooper wrote:
quoted
iiuc, Ted, you're saying using the hw_random framework would be
disasterous because despite most drivers having a default quality of 0,
rngd assumes 1 bit of entropy for every bit read?
Sorry, what I was trying to say (but failed) was that bypassing the
hwrng framework and injecting entropy directly the entropy pool was
disatrous.
Ok, whew. :)
quoted
Thankfully, most hw_random drivers don't set the quality.  So unless the
user sets the default_quality param, it's zero.
The fact that this is "most" and not "all" does scare me a little.
My recent grep showed that only virtio-rng set it to a non-zero value.
As far as I'm concerned *all* hw_random drivers should set quality to
zero, since it should be up to the system administrator.
Agreed.

Gathering conversation about this from a few related threads, I have one
concern.  Apparently there is some confusion in userspace consumers of
/dev/hwrng data as to the quality of it.  Specifically, rngd (spotted by
Stephan Mueller) appears to assume 1bit of entropy per 1 bit read. :-/

So, while moving ath9k-rng to the hwrng framework makes complete sense
internally, it's not so good for existing userspace assumptions.  I'd
think that timeriomem-rng falls in this same category.

In light of this, do you think it's worth the effort (I'm volunteering)
to create a subcategory of hwrng drivers that are 'environemntal' rngs?
They can contribute to the kernel entropy pools, but not to /dev/hwrng.

thx,

Jason.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help