Xml and More: WebLogic Startup Slowness Caused by Kernel's Random Number Generator

Thursday, September 26, 2013

WebLogic Startup Slowness Caused by Kernel's Random Number Generator

Java Application (i.e., WebLogic Server) could be slow at startup time and it could be caused by the slowness of random number generator used by the application. You can read [2] for the case that discusses the slowness of WebLogic startup.

In this article, we will examine the following issues:

/dev/random vs. /dev/urandom

How to test the performance of a random number generator?
How to configure it?

Security considerations

on Linux systems. Note that this can happen with WLS running on AIX too.

/dev/random vs. /dev/urandom

Without much ado, here is the man output for "urandom":

The character special files /dev/random and /dev/urandom (present since Linux 1.3.30) provide an interface to the kernel's random number generator. File /dev/random has major device number 1 and minor device number 8. File /dev/urandom has major device number 1 and minor device number 9.

The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created.

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

How to Test?

You can use "time" command to measure the performance of each random number generator. For example, here is the output from the Linux system.

$time head -1 /dev/random
real 0m9.718s
user 0m0.000s
sys 0m0.001s

$ time head -1 /dev/./urandom

real 0m0.002s

user 0m0.000s

sys 0m0.002s

As you can see that "/dev/urandom" is much faster because it's non-blocking. However, /dev/random will block until additional environmental noise is gathered and takes longer time to return.

How to Configure?

You can configure which source of seed data for SecureRandom to use at JVM level or at WLS' command-line level.

At the JVM level, you can change the value of securerandom.source property in the file:

$JAVA_HOME/jre/lib/security/java.security

Here is the description of securerandom.source property:

# Select the source of seed data for SecureRandom. By default an
# attempt is made to use the entropy gathering device specified by
# the securerandom.source property. If an exception occurs when
# accessing the URL then the traditional system/thread activity
# algorithm is used.
#
# On Solaris and Linux systems, if file:/dev/urandom is specified and it
# exists, a special SecureRandom implementation is activated by default.
# This "NativePRNG" reads random bytes directly from /dev/urandom.
#
# On Windows systems, the URLs file:/dev/random and file:/dev/urandom
# enables use of the Microsoft CryptoAPI seed functionality.
#
securerandom.source=file:/dev/urandom

Or, you can specify which source of seed data to use by adding

-Djava.security.egd=file:/dev/./urandom

to the java command-line that starts WebLogic Server.

Security Considerations

In [1], it warns that if you choose /dev/urandom over /dev/random for better performance, you should be aware of that:

This workaround should not be used in production environments because it uses pseudo-random numbers instead of genuine random numbers.