Ben Sandee wrote:
> Hi there,
> I'm investigating a case where a customer's prngd service was
> blocking, which by itself is not supposed to happen AFAIK. This was
> causing a hard-to-diagnose startup hang for our code that uses
> OpenSSL. The call to RAND_egd() was blocking in a call to read().

PRNGD should never hang. Which version of PRNGD are you using?
> I would like to address this issue so that even with a misbehaving
> prngd, our code will fail reliably rather than hanging. The
> documentation for RAND_egd() states specifically that non-blocking I/O
> is used to read from the EGD; analysis of the code leads me to believe
> otherwise, but I'm not particularly familiar with networking code.

Hmm. I just cross-read the manual page for RAND_egd(), please see below.
> Can anyone confirm my suspicions that the reads are indeed taking
> place using blocking sockets and that the documentation is wrong? I
> believe the code in question is in rand_egd.c and the documentation is
> in the RAND_egd.pod (the "Notes" section, second paragraph).

I get your point. I actually meant: RAND_egd() retrieves entropy from the
daemon using the daemon's "non-blocking read" command which shall
be answered immediately by the daemon without waiting for additional
entropy to be collected. The socket operations in the communication
are blocking.
I will fix the respective manual page.

Thus: if PRNGD is hanging the processes trying to read entropy are
as well. Fixing this is not trivial. We could move to non-blocking I/O
but this would involve some arbitrary timeout to be set. How large
should this timeout be?

Best regards,
Lutz (author of PRNGD)
__________________________________________________ ____________________
OpenSSL Project
User Support Mailing List
Automated List Manager