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 http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
