Bug 119526 - /proc/sys/kernel/random/entropy_avail goes to 0 and does not recover
/proc/sys/kernel/random/entropy_avail goes to 0 and does not recover
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mark DeWandel
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-30 21:52 EST by Jim Richard
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-02 00:31:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jim Richard 2004-03-30 21:52:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
Gecko/20011019 Netscape6/6.2

Description of problem:
When available entropy becomes exhausted for an extended period of
time it fails to recover no matter what actions are taken. The only
action that gets entropy stirred back into the pool is a reboot. 

This behavior occurs in server environments (read no mouse or
keyboard). I've seen it in both rh el as 3 and rh 8. Kernels
2.4.21-9.0.1.ELsmp and 2.4.20-20.8smp. The situation happens on
systems that are primarily web servers and others that are database
servers. 

Both environmens make extensive use of ssl and ssh. All services are
configured to use /dev/urandom so blocking is not a problem but we are
concerned by the reduced cryptographic quality of using a PRNG instead
of real entropy. 

I've gone as far as to implement a script that monitors for the
situation(entropy less then 8192 bits)  and  attempts to stir entropy
by executing disk intensive commands such as find /; man -K  the
process disk ; cat /var/logs/* ... etc.

I've bumped the poolsize to max of 8192. (65536 bits)

The script helps but does not eliminate the problem.

I've googled this and seen references to accounting problems related
to the entropy pool but nothing about the pool not recovering from an
exhausted state. 

I'd very much like to see this addressed in the near term. This seems
to be an area where there is much controversy. So I'd like to
understand RH plans; in order for me  determine if I should be looking
for an alternative/external source for cryptographic quality
randomness. If RH has no plans to address this then I can look at
other sources. But since the OS is advertised to handle this I'd
prefer not to. 

Version-Release number of selected component (if applicable):
2.4.21-9.0.1.ELsmp (rhel as 3) & 2.4.20-20.8smp ( rh 8)

How reproducible:
Always

Steps to Reproduce:
1. setup server without active mouse or keyboard activity
2. start any application that make heavy use of /dev/urandom or
/dev/random, such as ssh; apache with mod ssl; RH cluster suite... etc.

    

Actual Results:  entropy_avail goes to 0 after an unspecified amount
of time; and never recovers 

Expected Results:  entropy_avail increases when I/O or other interrupt
driven events occur.

Additional info:
Comment 1 Ernie Petrides 2004-03-31 17:35:40 EST

*** This bug has been marked as a duplicate of 117218 ***
Comment 2 John Flanagan 2004-09-02 00:31:12 EDT
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-433.html

Note You need to log in before you can comment on or make changes to this bug.