lkml.org 
[lkml]   [2013]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] /dev/random: Insufficient of entropy on many architectures
On Thu, Sep 12, 2013 at 01:59:04PM +0200, Geert Uytterhoeven wrote:
>
> BTW, I prefer a different name than "random_get_fast_cycles()", as it's better
> to have something that returns different and unpredictable numbers than an
> actual monotonic cycle counter.

I'm open to a different name; the point I was trying to make with that
name proposal was to be clear that it had to be very low overhead, and
that the intent of this interface was that it be time dependent in
some fashion (since that is how we are trying to generate the entropy
source). The problem with "time" is that it implies that it is in
units of seconds. I was trying to come up with something that was
more generic, which is why I suggested "randome_get_fast_cycles()".

If the CPU has a source which is specified to be complately
unpredictable, we have arch_get_random_long(), which the random driver
uses as well.

I get that there could be other things, such as some kind of dram
refresh counter, or the raster scan line if you had an embedded video
chip on something like an Apple II :-) and thse things would work too.

But if someone can suggest a different name, sure, let's talk about
it. It may be, though, that the best we can do is to pick a name
which is not too misleading, even if it is not 100% precise. That can
happen sometimes, alas.

Regards,

- Ted


\
 
 \ /
  Last update: 2013-09-12 16:41    [W:0.141 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site