Re: [uml-devel] Strange behaviour of hwrng

[Gerd S. <in...@ge...>]

Am Freitag, den 21.10.2005, 20:42 +0200 schrieb Blaisorblade:
> On Friday 21 October 2005 20:24, Gerd Stolpmann wrote:
> > Hi list,
> >
> > I recently tested the hwrng driver. In principal, it works, but it
> > sometimes eats up all host CPU time. In particular, I can see that the
> > UML system does a (blocking) read on /dev/hwrng,
> 
> Could you please elaborate on that? Who is doing the read, the rng tools? 

Yes, one of the rngd threads is doing the read:

play:~# strace -p 517
Process 517 attached - interrupt to quit
read(3,  <unfinished ...>

top shows it consumes 12.5% CPU time (on the UML system) although it is
blocking, I guess it is system time accounted for this process. On the
host system, UML consumes more than 70% CPU time.

> Also, are they doing only a single read (in which case, it's we the ones who 
> are looping and we're broken) or they are astonished by our -EAGAIN and keep 
> trying (in which case, they are broken)?

Obviously, they don't get the -EAGAIN, so they are only doing a single
read. (We should see the -EAGAIN with strace if it occurred, shouldn'd
we.)

> Actually, from looking at the code (arch/um/drivers/random.c:rng_dev_read()) 
> it appears that we _do_ loop ourselves, if the read is blocking. Not sure how 
> to handle that.

I think this is the problem.

> We could return maybe -EIO, possibly when a rate limit is exceeded (not 
> trivial to do, though - I must learn using timers first).

Maybe an opportunity...

> > and that the host 
> > system loops while reading from /dev/random which almost always returns
> > -EAGAIN. (Found that out with strace, in the hope the output is
> > correct.)
> 
> Well, if the host hasn't enough entropy, it's reasonable for it to return 
> -EAGAIN.

Of course, it it will do most of the time.

> And we should do the same (the loop is actually executed by the UML code, 
> right?).

If the descriptor is non-blocking.

> However, probably the tools inside UML don't expect a lot to get -EAGAIN from 
> an hardware generator. So possibly they are not ready to handle that well.

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.

(2) Fix /dev/hwrng such that it blocks when it is out of entropy. Looks
like the same problem, only within the kernel.

Gerd

> 
> > Nevertheless rngd seems to work, because when killing with SIGUSR1 it
> > shows some reasonable statistics.
> 
> > My test setup is as follows:
> 
> > - Host system: 2.6.12.6 with SKAS3 v8.2 patch
> > - UML system: 2.6.14-rc5, in SKAS3 mode.
> >   Using rngd from Debian Sarge.
> >   TLS is disabled.
> 
> > Let me know if you need more information.
> 
> > Gerd
> 
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
ge...@ge...          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------