Am Samstag, den 22.10.2005, 02:52 +0200 schrieb Blaisorblade:
> > Obviously, the real hardware generators block when there is not enough
> > entropy, and rngd was written for them. I think there are two ways of
> > fixing the problem:
>
> > (1) Change rngd. If it sees -EAGAIN, it sleeps for a moment. This is not
> > easy, because it has to find out the available bit rate of entropy, in
> > order to determine a reasonable frequency of polling /dev/hwrng.
> We could implement poll() for that purpose,
> > (2) Fix /dev/hwrng such that it blocks when it is out of entropy. Looks
> > like the same problem, only within the kernel.
>
> Proper solution: use a separate _host_ thread, which either sits blocked in a
> blocking read or calls poll() on the host /dev/random, and have it do the
> work. It's not easy however.
> The ubd driver works currently this way, but the thing is not trivial to get
> right (and the UBD rewrite in the works has shown that).
>
> A simpler solution is to increase the parameter passed to schedule_timeout.
> We
> currently sleep for one hundredth of second (actually one jiffy).
>
> But only if need_resched(), which is wrong. I.e. if a timeslice lasts 80 ms
> (as is possible) we'll sleep 1 ms every 80 ones, which is unfair. Also,
> there's no need to continously poll the host /dev/random.
>
> So, in rng_dev_read, in this piece of code:
> if(need_resched()){
> current->state = TASK_INTERRUPTIBLE;
> schedule_timeout(1);
> }
>
> Remove the need_resched() checking, and retest. You can also test increasing
> the param to schedule timeout (it's currently 10 ms, but it's better to use
> HZ to mean a second and, say, HZ/100 to mean 10ms).
Ok, I tested that with schedule_timeout(HZ), i.e. it polls once per
second. This looks good enough for the case that the host /dev/random is
slow. rngd reports that it gets about 60 random bits/sec, which is about
the same as before with busy waiting.
The code looks now:
if(1){
current->state = TASK_INTERRUPTIBLE;
schedule_timeout(HZ);
}
It would be interesting how well this works for a hardware entropy
generator. I don't have such a board, however.
Another question is how fair we are. It may happen that host processes
like sshd starve that need entropy only from time to time, because all
randomness was pulled out of /dev/random from greedy UML kernels.
Ideally, the UMLs take only entropy when the entropy pool is filled to a
certain watermark at minimum.
Gerd
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
[EMAIL PROTECTED] http://www.gerd-stolpmann.de
Telefon: 06151/153855 Telefax: 06151/997714
------------------------------------------------------------
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
