[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160814181114.GM2013@io.lakedaemon.net>
Date: Sun, 14 Aug 2016 18:11:14 +0000
From: Jason Cooper <jason@...edaemon.net>
To: Theodore Ts'o <tytso@....edu>,
"Pan, Miaoqing" <miaoqing@....qualcomm.com>,
Stephan Mueller <smueller@...onox.de>,
"Sepehrdad, Pouyan" <pouyans@....qualcomm.com>,
"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
ath9k-devel <ath9k-devel@....qualcomm.com>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ts.ath9k.org>,
Kalle Valo <kvalo@...eaurora.org>
Subject: Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
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:
> > 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. :)
> > 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.
Powered by blists - more mailing lists