Bug 1540907

Summary:	Use native SecureRandom implementation instead of SHA1PRNG
Product:	[oVirt] ovirt-engine	Reporter:	Martin Perina <mperina>
Component:	AAA	Assignee:	Martin Perina <mperina>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Lukas Svaty <lsvaty>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	---	CC:	bugs, lsvaty, lveyde, rgolan
Target Milestone:	ovirt-4.2.2	Keywords:	CodeChange
Target Release:	---	Flags:	rule-engine: ovirt-4.2+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-engine-4.2.2	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-03-29 11:12:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Martin Perina 2018-02-01 09:57:06 UTC

Probably from historical reasons engine was using SHA1PRNG implementation for random number generation. SHA1PRNG is pseudo-random number generator implemented within JVM (more details at [1]) and it's blocking implementation (it can block the entire process if there is not enough entropy), which could cause issues when engine is running inside a VM.

We should switch to NativePRNG, which is blocking only for seed generation. More information about Java implementation is available at [1] and [2].


[1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SecureRandom 
[2] https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/

Comment 1 Roy Golan 2018-02-06 07:21:17 UTC

Running systems out there may benefit by simply setting the JRE to use /dev/urandom in java.security property file:

 $JAVA_HOME/jre/lib/security/java.security
 ...
 securerandom.source=file:/dev/urandom

Comment 2 Martin Perina 2018-02-06 09:33:11 UTC

(In reply to Roy Golan from comment #1)
> Running systems out there may benefit by simply setting the JRE to use
> /dev/urandom in java.security property file:
> 
>  $JAVA_HOME/jre/lib/security/java.security
>  ...
>  securerandom.source=file:/dev/urandom

I'd personally rather not change the platform default. And also I'm not sure if this will affect us, because AFAIK SHA1PRNG is custom Java implementation and not sure if it uses /dev/(u)random or not. That's why I think it's better to switch from SHA1PRNG to NativePRNG without changing JVM default.

Comment 3 Roy Golan 2018-02-06 16:29:54 UTC

(In reply to Martin Perina from comment #2)

> I'd personally rather not change the platform default.

I mentioned this is for existing setups that may suffer from it.

> And also I'm not sure
> if this will affect us, because AFAIK SHA1PRNG is custom Java implementation
> and not sure if it uses /dev/(u)random or not.

According to the sources you mentioned in the patch and reading the oracle implementation it does look like they are using the device that is mentioned java.security

> That's why I think it's
> better to switch from SHA1PRNG to NativePRNG without changing JVM default.

Comment 4 Lukas Svaty 2018-03-07 09:49:12 UTC

adding CodeChange moving to VERIFIED

Comment 5 Martin Perina 2018-03-07 13:15:41 UTC

BZ1421472 is the original bug, I have found this issue when investigating it. So I think you can use the same reproducing steps to verify it.

Comment 6 Sandro Bonazzola 2018-03-29 11:12:52 UTC

This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.