Re: NetBSD openjdk SecureRandom /dev/random "Resource temporarily unavailable" issue

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Thu, 28 Apr 2016 09:44:21 +0000
coypu%SDF.ORG@localhost wrote:

> On Thu, Apr 28, 2016 at 10:29:56AM +0100, David Brownlee wrote:
> > With the default openjdk8 settings the following code
> > 
> > private static final int SALT_LENGTH = 32;
> > private static final String RANDOM_FACTORY = "SHA1PRNG";
> > byte[] saltBytes =
> > SecureRandom.getInstance(RANDOM_FACTORY).generateSeed(SALT_LENGTH);
> > 
> > Fails with an exception:
> > 
> > register: Error registering subscriber: java.io.IOException: Resource
> > temporarily unavailable
> >         at java.io.FileInputStream.readBytes(Native Method)
> >         at java.io.FileInputStream.read(FileInputStream.java:255)
> >         at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539)
> >         at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
> >         at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:139)
> >         at java.security.SecureRandom.generateSeed(SecureRandom.java:533)
> > 
> > Adjusting lib/security/java.security to switch securerandom.source
> > from file:/dev/random to file:/dev/urandom works around the issue.
> > 
> > Does anyone know if NetBSD's /dev/random behaving differently to other
> > platforms here?
> > 
> > David
> 
> It's possible this behaviour does not exist with NetBSD /dev/random and
> is expected by Java (from linux RANDOM(4)):
> 
> If open(2) is called for /dev/random with the flag O_NONBLOCK, a
> subsequent read(2) will not block if the requested number of bytes
> is not available. Instead, the available bytes are returned.  If no
> byte is available, read(2) will  return  -1  and errno will be set
> to EAGAIN.

But this is supposed to be a blocking read. Why does NetBSD return
EAGAIN in blocking mode? I can kind of appreciate why 3rd party
applications would not expect this to happen. At least we need to
update rnd(4) to mention this fact and how to get blocking behaviour
since it is different from how other systems behave.

-Tobias