Bug 200653

Summary:	rebuild-security-providers should set securerandom.source
Product:	[Fedora] Fedora	Reporter:	Anthony Green <green>
Component:	jpackage-utils	Assignee:	Thomas Fitzsimmons <fitzsim>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	aph, csm, tromey
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-08-30 17:55:02 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 Anthony Green 2006-07-30 00:44:24 UTC

Description of problem:
When I run azureus on rawhide, VMSecureRandom::Spinner::run() consumes about 70%
of my CPU (as reported by oprofile), making the system as whole quite unusable.
 I don't know what's up with that method, but we can avoid the whole mess by
adding the following line to /usr/lib/security/classpath.security:

securerandom.source=file:/dev/random

This is what Casey recommends anyways here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

My system was practically unusable when I was running azureus before I made this
change, but now it seems fine.

It looks like this would have to happen in rebuild-security-providers.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Generate secure random numbers with gcj 
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Casey Marshall 2006-07-30 20:36:50 UTC

The pegged-CPU issue was caused by GCJ not supporting `volatile' properly; this
should be fixed on trunk. If not, you might want to reopen GCC bug 27908. Note,
it's pretty simple to work around, too (see comment 8 in that bug).

But also, setting `securerandom.source' to `/dev/urandom' is a perfectly fine
solution on GNU/Linux (using `/dev/random' may cause your program to hang), and
is preferable, because we don't really know how good the random bytes we create
using thread-spinners are.

Comment 2 Andrew Haley 2006-07-31 09:57:40 UTC

I can confirm this is fixed on trunk, not on 4.1 branch.

Comment 3 Thomas Fitzsimmons 2006-07-31 14:39:24 UTC

This would be fixed by the GNU Classpath 0.92 backport.

Comment 4 Anthony Green 2006-07-31 14:44:49 UTC

(In reply to comment #3)
> This would be fixed by the GNU Classpath 0.92 backport.

How is this fixed?  Is /dev/urandom the default random number source in 0.92?

Comment 5 Thomas Fitzsimmons 2006-07-31 14:46:56 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > This would be fixed by the GNU Classpath 0.92 backport.
> 
> How is this fixed?  Is /dev/urandom the default random number source in 0.92?
> 

Yes, see mjw's note on fedora-devel-java-list.

Comment 6 Thomas Fitzsimmons 2006-08-30 17:55:02 UTC

Fixed in Rawhide by the latest libgcj backport.  classpath.security now has this
line:

securerandom.source=file:/dev/random