Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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: |
Description
Stefan Neufeind
2004-03-22 20:23:11 UTC
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/ |