> To provide a "reserved" pool with a guarantee of this strength requires
> that some input entropy be set aside for root-only use and not used to
> generate user random output. Which takes up more data space in the
> kernel and makes the output weaker.
>
> Doing this without slowing down the entropy-gathering operation (which
> is triggered each interrupt, so it has to be *fast*) is also tricky.
>
> Frankly, I don't see the point.
Is there a call to set the pool size? What seems to happen is that I am
running a test (multiple cycles, each starting with an empty random
startup) on something that grabs data from /dev/random and then it simply
sits there until I hit the shift key several times. Most of the normal
usage of this is fixed by going to /dev/urandom, but it would also be nice
to have a larger pool, so it would gather things now while I am typing
this for use later when I am testing.
> Oh, a question for folks who understand the multi-platform coding style.
> On the Pentium, /dev/random takes advnatage of the clock cycle counter
> to get as much timing information as posible. Many other processors
> have this too (Alpha, MIPS, PowerPC, ...) and it would be nice for it
> to work on them too. Is there a better way to do this than to have
> a zillion #ifdefs? It's just a couple of lines of inline asm per
> platform. Should the function go into <asm/foo.h> somewhere? What
> should it be called, and where should it go?
> --
> -Colin
The problem is that some processors/systems don't have such a counter, but
you are correct that it should go somewhere in the asm directory, maybe
asm/random.h or asm/entropy.h - you would still seed an #ifdef or two for
the specific processor, or system.
--- reply to tzeruch - at - ceddec - dot - com ---