Re: [PATCH 01/11] random: don't feed stack data into pool when interrupt regs NULL

[Sebastian Andrzej Siewior]

On 2014-04-07 00:01:37 [-0400], Theodore Ts'o wrote:
> Yes, ARM sucks for not implement random_get_entropy() on all
> platforms.  Film at 11.  I'm told that Cortex ARM systms are supposed
> to have a cycle counter.  I'm not sure why it hasn't been wired up,
> but it really should be.

I see.

> Actually regs should be available nearly all of the time.  So the
> situation isn't quite as dire as you describe, but agreed, it is
> pretty bad.

You dropped that part where I suggested to use something like AES+CTR
and create the numbers on demand and dropping that attempt to create as
much random data with custom functions as possible. You completly dislike
that approach? And if so, why?

> Still, it would be nice if random_get_entropy() could be wired up on
> as many platforms as possible.  

Yes. Usually there is generic function doing something sane but not as
good as it could do with arch specific code. Or the code is completly
disabled unless the architecture wires it up. Dropping a new function and
hoping everyone will wire it up in no time is, ehm, brave. Nobody implemented
random_get_entropy(), everyone falls back to get_cycles. From a quick
grep I can see that atleast Hexagon, Cris, Frv, m32r and m68k return 0. I 
put some of the maintainers Cc, I am curious if they know about the side
effects.

> This is lacking in subtly, and while I'm sympathetic with your
> frustration, and unfortunately, there are a huge number of CPU's/SOC's
> that don't implement a cycle counter or some other kind of cheap, high
> resolution counter.  I'm not against putting in a warning printk, but

Cheap? I know there a few platforms running on a 16bit counter. It is
enough for a high resolution timer, it overflows quite often, too (i.e.
in less than two seconds). However it is the only thing as time base that
they have and from clocksource point of view it is enough.

> issuing a WARN_ON(1) would be really be too obnoxious.  Maybe
> something like, "you're running on a crap CPU architecture and so
> /dev/random may very well be insecure", but I think that's about as
> blunt as we can really afford to be at this point.

A backtrace is something you catch during boot up. A single line may get
lost in the mass and I think this is important.
However, as you wish, here are the changes.

> 
> 	     	    	   	     - Ted
> 
> P.S.  Maybe if Intel started a marketing campaign on G+ explaining why
> ChromeOS on Intel machines is much more secure than ChromeOS on ARM,
> we could finally get some action out of the !@#!?! ARM chip
> manufacturers.  :-/

Maybe post people are not aware what is going on here. A huge campaing
with ballons is one way to get attention. Just drop /dev/random if the
missing infrastucture isn't available and it shouldn't need G+ to get
the infrastrucure. And the CTR thingy might be a good one because it
would require *one* thing to get done and not each arch/subarch.