lkml.org 
[lkml]   [2013]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] /dev/random: Insufficient of entropy on many architectures
Date
Am Dienstag, 10. September 2013, 14:25:24 schrieb Theodore Ts'o:

Hi Theodore,

>
>Also note that the clocksource is not necessarily be the best choice;
>it may not be the most fine grained sampling that we have available
>(that is certainly be true for MIPS). So doing something hacky
>doesn't absolve us from the need to example every single platform that
>as a no-op get_cycles() function. (Well, at least those platforms
>that we think really are going to be running security sensitive
>systems ---- does anyone think we really have production systems
>running m68k? Maybe, but....)

That is why I arranged the clocksource call after get_cycles does not
return anything, so it would only be used if get_cycles does not have
anything.

But then, your experience with clocksource really has a point.
>
>If we believed that /dev/random was actually returning numbers which
>are exploitable, because of this, I might agree with the "we must do
>SOMETHING" attitude. But I don't believe this to be the case. Also
>note that we're talking about embedded platforms, where upgrade cycles
>are measured in years --- if you're lucky. There are probably home
>routers still stuck on 2.6, at which point they will be far more
>succeptible to the problems described at http://factorable.net.

The core problem I guess on this matter is again the strange use of
/dev/random in embedded devices -- no seeding, no spinning disks, no
heads, no nothing.

Here my CPU jitter RNG would help, but there seems to be no interest in
even discussing it... PS: I have my CPU jitter RNG running running as an
entropy feeder daemon nicely on my router box, though, which happens to
be a MIPS box...
>
>So I don't think we need to rush. I'd much rather make sure we get
>this fixed right.
>
> - Ted


Ciao
Stephan


\
 
 \ /
  Last update: 2013-09-10 21:21    [W:0.064 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site