适用于 Linux 和 RandomSource 的 Oracle Java 8 x64 [英] Oracle Java 8 x64 for Linux and RandomSource

问题描述

我真的认为在各种平台上安装了大约 200 个或更多的 tomcat 之后，我已经准备好迎接任何类型的挑战，但这个挑战很棘手.

I really thought that after about 200 or more tomcat installs on various platforms, I am ready for any kind of challenge but this one is tricky.

我创建了一个普通的 Ubunutu 14_04 映像，并在该系统上从 oracle 安装了 Java 8 TGZ.此外，我在游戏中添加了一个 tomcat 8.然后我开始安装 vanilla 服务器.

I created a vanilla Ubunutu 14_04 image and installed Java 8 TGZ from oracle on that system. Furthermore I added a tomcat 8 to the game. Then I started the vanilla server install.

在部署了 tomcat 附带的默认应用程序后不久，我想知道那里发生了什么并做了一些线程转储.这是阻止tomcat启动的糟糕线程:

Soon after hanging on deploying the default apps shipped with tomcat, I wondered whats happening there and did some threaddumps. This one was the lousy thread who prevented tomcat from starting:

"localhost-startStop-1" #15 daemon prio=5 os_prio=0 tid=0x00007f37c8004800 nid=0x4d6 runnable [0x00007f37b38b3000]
   java.lang.Thread.State: RUNNABLE
    at java.io.FileInputStream.readBytes(Native Method)
    at java.io.FileInputStream.read(FileInputStream.java:246)
    at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539)
    at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
    at sun.security.provider.SecureRandom$SeederHolder.<clinit>(SecureRandom.java:192)
    at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:210)
    - locked <0x00000000f06e6ce8> (a sun.security.provider.SecureRandom)
    at java.security.SecureRandom.nextBytes(SecureRandom.java:457)
    - locked <0x00000000f06e71c0> (a java.security.SecureRandom)
    at java.security.SecureRandom.next(SecureRandom.java:480)
    at java.util.Random.nextInt(Random.java:329)
    at org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom(SessionIdGeneratorBase.java:234)

经过更多 google &朋友们，我发现 JDK 附带的 SeedGenerator 是我问题的根源.有趣的是，有时 SeedGenerator 在几分钟后又回来了，有时它只是挂了(熵用完了?...通过 cat/proc/sys/kernel/random/entropy_avail 检查).经过更多研究，我发现 $JAVA_HOME$/lib/security/java.security 中名为 securerandom.source 的配置变量定义了 Random 的来源.在我的情况下，或者在 Linux 的 oracle JDK 8 安装中更好，它是 /dev/random.我不是 Linux 专家(我是 Java 开发人员)，但我的理解是 /dev/random 可能会耗尽熵(无论这意味着什么)，但也许这意味着在某些时候它无法生成任何更多的随机数).我切换到 /dev/urandom 并且我的 tomcat 一切正常.

After more google & friends i discovered that the SeedGenerator shipped with the JDK is the source of my problem. Interestingly sometimes the SeedGenerator came back after several minutes and sometimes it just hung (running out of entropy? ... checked via cat /proc/sys/kernel/random/entropy_avail) . After more research I found out that a config variable in $JAVA_HOME$/lib/security/java.security called securerandom.source defines what the source for Random is. In my case, or better in the oracle JDK 8 install for linux, it was /dev/random. I am not a Linux expert (I am a java developer) but what I understood is that /dev/random can run out of entropy (whatever this means) but perhaps it means at some point it cant generate any more random numbers). I switched to /dev/urandom and everything was fine with my tomcat.

然后我检查了其他 JDK 安装在我的其他各种服务器上的样子，这些服务器是 OpenJDK 和旧版 Oracle JDK 安装的狂野组合.至少 OpenJDK 总是使用 /dev/urandom 答案可能是什么，为什么我以前从未遇到过这个问题.

Then i checked how other JDK installs look like on my other various server, which were a wild mix of OpenJDK and older Oracle JDK installs. At least OpenJDK always used /dev/urandom what might be the answer, why I have never had the problem before.

现在我的问题:当可能存在操作系统无法产生更多数字的极端情况时，Oracle 依赖 /dev/random 是否理智?我的意思是像 Tomcat 和许多其他服务器依赖于 JDK 的 SeedGenerator 并且调试这种错误真的很先进.我花了 2 个小时才到达现在的地步.

Now to my question: Is it sane from Oracle to rely on /dev/random when there can be corner cases where the OS cant produce any more numbers? I mean servers like Tomcat and many others rely on SeedGenerator from the JDK and debugging this kind of error is really advanced. Took me 2 hours to get to the point where i am now.

推荐答案

我认为答案依赖于 WebLogic 支持的这个链接:https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html他们提到随机"的地方更安全

I think the answer relies in this link for WebLogic support: https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html where they mention that "random" is more secure

以及 Oracle 错误评论(David 已经提到):http://bugs.java.com/view_bug.do?bug_id=4705093

and also in the Oracle bug comment (already mentioned by David): http://bugs.java.com/view_bug.do?bug_id=4705093

特别是关于这部分:

因为 SHA1PRNG 是基于 MessageDigest 的 PRNG，所以如果应用程序未提供种子数据，它历来总是使用/dev/random 进行初始播种.由于所有未来值都取决于 MessageDigest 的现有状态，因此从强大的初始种子开始非常重要.

Because SHA1PRNG is a MessageDigest-based PRNG, it historically has always used /dev/random for initial seeding if seed data has not been provided by the application. Since all future values depend on the existing state of the MessageDigest, it's important to start with a strong initial seed.

改变这种行为让最初的开发者感到不安.所以他确实创建了一个名为 NativePRNG 的新 SecureRandom impl，它确实尊重 java.security.egd 值.

Changing that behavior was troubling to the original developer. So he did created a new SecureRandom impl called NativePRNG, which does respect the java.security.egd value.

如果你打电话:

• Linux 上的 new SecureRandom() 使用默认值，它将从/dev/urandom 读取而不是阻塞.(在 Solaris 上默认使用 PKCS11 SecureRandom，并且还会调用/dev/urandom.)

• new SecureRandom() on Linux and the default values are used, it will read from /dev/urandom and not block. (By default on Solaris, the PKCS11 SecureRandom is used, and also calls into /dev/urandom.)

SecureRandom.getInstance("SHA1PRNG") 并且不指定种子，OR new SecureRandom() 但指定了除file:/"之外的替代 java.security.egddev/urandom"，它将使用调用/dev/random 的 SHA1PRNG 并且可能会阻塞.

SecureRandom.getInstance("SHA1PRNG") and do not specify a seed, OR new SecureRandom() but have specified an alternate java.security.egd besides "file:/dev/urandom", it will use the SHA1PRNG which calls into /dev/random and may potentially block.

SecureRandom.getInstance("NativePRNG")，这取决于 java.security.egd 指向的内容.

SecureRandom.getInstance("NativePRNG"), it will depend on what java.security.egd is pointing to.

这篇关于适用于 Linux 和 RandomSource 的 Oracle Java 8 x64的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！