Bug 118921
| Summary: | /dev/random runs out of entropy | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stefan Neufeind <redhat> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | CC: | bugs-redhat, jcmontz, jrichard, leonard-rh-bugzilla |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-29 20:13:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
AFAICT /dev/random running out of entropy is expected behaviour. It needs input for new entropy. This is why /dev/urandom is there. I would say NOTABUG, but wont close as I am not 100% sure. man 4 random states: When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. I.e. known behaviour. Closing NOTABUG. The blocking is expected - right! But the entropy pool does not fill again. Using /dev/urandom instead (see the "dirty quickfix" provided) helps, but degrades security since urandom produces weaker random bytes (less security) :-(( My mistake. Sorry for that. So this problem also exists on single CPU FC 1 machines. I cannot reproduce it easily on my machine, but that is a desktop. Not sure if it is relevant, but what is your hardware setup? board: P4B533-V chipset: Intel 82845G MCH & Intel 82801 ICH4 cpu: Intel PIV 2.4Ghz also see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119526 it seems to be reproducable for Jim. Maybe it could be reproduced by stresstesting (exhausting) /dev/random and wait for it to recover? Unfortunately I don't have test-system at hand right now, but could somebody with more in-sight-knowledge *please* have a look? The problem seems to be quite essential imho. Just want to monitor, I've a similar bug open against RHEL... see Bug#s 117218 and 119526. This condition is very re-producable on any system that makes extensive use of SSH, SSL, I also see it on RHEL clusters since cluster daemons appear to access /dev/urandom. Also Google search yields a long and disperate list of problems in this area, try the following search criteria: +linux +/dev/random +entropy One of the problems here is sources of entropy. Not all systems have a lot of sources - especially those that are not using keyboard/local disk a lot I'm having this problem on Fedora Core 1. CPU: 2 x Xeon 2GHz Motherboard: Intel SE7501BR2 Storage: Hardware RAID-5 Array of Serial-ATA disks on 3Ware Escalade 8506-4LP controller. Isn't writing to /dev/random supposed to reseed the entropy pool? If it is, then it doesn't work. When I do the following I don't get any mor entropy: dd if=./some_binary_file of=/dev/random bs=512 count=1 Also, waiting any amount of time doesn't help, the entropy stays at 0: $ sysctl kernel.random.entropy_avail kernel.random.entropy_avail = 0 Also, moving the mouse and tapping keys on the keyboard doesn't fill the entropy pool - something is clearly wrong. This is on kernel 2.4.22-1.2188.nptlsmp. I've never seen such things on this machine with previous Fedora kernel versions, but this might only be a coincidence. The problem also occurs on RHEL kernel! A Fedora Core 1 host running RHEL kernel 2.4.21-15.ELsmp (switched to RHEL kernel because of bug 123332) has the same problem right now. Any ideas how to debug it? Just wanted to share some information with everyone on this issue. Agreed, that it is ultimately an issue with /dev/random, but I was curious as to what exactly was using /dev/random so much as to exhaust it. In our particular instance, we have a Java application that uses SSL extensively. (Sun J2SDK 1.4.2), which used /dev/random specifically. There is an option in java.security to specify the "entropy gathering device", either in java.security, or by overriding the option on the command line. We have implemented the command line option on the java instance in question and are currently testing. (- Djava.security.egd=file:/dev/urandom) I will post an update if this ultimately resolves the issue. Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/ |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera 7.23 [en] Description of problem: Reads to /dev/random block unexpectedly because there is no entropy anymore. sysctl -A | grep random kernel.random.entropy_avail = 0 The system is a server, so I can't unfortunately generate keyboard or mouse "input" to try if entropy is generated again by that. Tried doing some disc-I/Os by "find / -name abc" or something - but it didn't help ... maybe cause the filesystem was already completely in mem-cache. It's an IDE-machine. Is network not used for entropy? The system is running a network services, so there is definitely network-traffic. Version-Release number of selected component (if applicable): kernel-2.4.22-1.2174.nptl How reproducible: Always Steps to Reproduce: 1. dd if=/dev/random of=testfile bs=1 count=1 2. 3. Actual Results: dd hangs, cause /dev/random does not output anything (due to missing entropy) Expected Results: testfile should be written with any random character Additional info: I believe this bug is quite grave, since it hangs some programs completely, which need /dev/random. Dirty quickfix: rm /dev/random mknod -m 0444 /dev/random c 1 9 This maps /dev/random to /dev/urandom. It's less secure, but works for the moment. However, the bug urgently needs fixing if possible. Also see: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117218 which refers to RedHat Enterprise Linux