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

[Jason Cooper <jason@lakedaemon.net>]

Hi Ted,

On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 06:30:03AM +0000, Pan, Miaoqing wrote:
> > Agree with Jason's point, also understand Stephan's concern.  The
> > date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> > 1000', the average speed is 1111.294Kibits/s. I will sent the patch
> > to disable ath9k RNG by default.
> 
> If the ATH9K is generating some random amount of data, but you don't
> know how random, and you're gathering it opportunistically --- for
> example, suppose a wireless driver gets the radio's signal strength
> through the normal course of its operation, and while there might not
> be that much randomness for someone who can observe the exact details
> of how the phone is positioned in the room --- but for which the
> analyst sitting in Fort Meade won't know whether or not the phone is
> on the desk, or in a knapsack under the table, the right interface to
> use is:
> 
>    void add_device_randomness(const void *buf, unsigned int size);
> 	
> This won't increase the entropy count, but if you have the bit of
> potential randomness "for free", you might as well contribute it to
> the entropy pool.  If it turns out that the chip was manufactured in
> China, and the MSS has backdoored it out the wazoo, it won't do any
> harm --- where as using the hwrng framework would be disastrous.

Ok, I get that.  However, we have Documentation/hw_random.txt saying:

  This data is NOT CHECKED by any fitness tests, and could potentially be
  bogus (if the hardware is faulty or has been tampered with).  Data is
  only output if the hardware "has-data" flag is set, but nevertheless a
  security-conscious person would run fitness tests on the data before
  assuming it is truly random.

Which I would read as "Don't assume 1 bit read from /dev/hwrng equals 1
bit of entropy."  Which runs counter to Stephan's reading of the rngd
code.

And then we have drivers like timeriomem-rng.c that appear to be
spitting out the raw 32bit register value of $SOC's timer.

Thankfully, most hw_random drivers don't set the quality.  So unless the
user sets the default_quality param, it's zero.

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?

thx,

Jason.