[SNMP4J] SecureRandom freezes JVM

[Sasa Markovic]

Well, the problem is finally resolved :)

As I expected, the problem was not with Java or SNMP4J at all. The real 
troublemaker was my SCSI disc driver (dac960). Yes, it sounds funny but 
it's true. The driver had excellent I/O performance but it was not 
written properly as a part of IDE/SCSI sublayer which feeds the entropy 
pool on a regular basis. So we had to patch it by adding something like 
add_disk_randomness() in proper places. Note that our server is a 
standalone machine without keyboard and mouse - therefore, no additional 
entropy generators could be used.

Best regards,
Sasa.



Sasa Markovic wrote:
> Philip Yarra wrote:
> 
>> I think this will be because by default, Java will get entropy data 
>> from /dev/random, which blocks until data is available. We had a 
>> similar issue on an extremely busy system, where the pool would be 
>> emptied faster than it could be filled... after a while, Java simply 
>> stopped. In your case, maybe there is some problem with /dev/random?
>>
>> In any case, the simple workaround is to use /dev/urandom, which is 
>> non-blocking. Hopefully /dev/urandom is okay too. See 
>> http://forum.java.sun.com/thread.jspa?threadID=230198&messageID=820456 
>> for more detail. Note that other utilities (ssl, ssh, etc) will also 
>> rely on /dev/random, so the best course might be to make sure that 
>> /dev/random works properly.
> 
> 
> I have replaced /dev/random with /dev/urandom (it's possilbe to do this 
> from the java command line) but /dev/urandom does not work either. JVM 
> freezes and 'fuser' finds that both /dev/random and /dev/urandom are 
> 'open'. I know that 'urandom' should not block, but it happens.
> 
> I think this is some Gentoo-related problem. Here is an interesting 
> thread which helped me a lot to understand the problem in detail (it's 
> all about apache and /dev/random, but the story is still relevant):
> 
> http://www.linode.com/forums/viewtopic.php?t=650
> 
> According to this, /dev/random should be populated by random bytes 
> generated by some low-level events, like disk I/O or NIC utilization. 
> It's fun to know that the number of bytes currently available in the 
> /dev/random entropy generator can be found with:
> 
> cat /proc/sys/kernel/random/entropy_avail
> 
> On our Gentoo server, it returns '2', probably not enough for a single 
> successful seed retrieval. A book says that this value should rapidly 
> increase over time (I/O intensive operations might help, like "du 
> /usr"), but Gentoo keeps returnig '2' forever. I have replaced the 
> kernel with a newer one, but all I got so far was '0' instead of '2' :)
> 
> A tough nut to crack.
> 
> Greetings,
> Sasa
> 
>>
>> Regards, Philip.
>>
>> On Tue, 25 Jan 2005 01:05 am, Sasa Markovic wrote:
>>
>>> Hi.
>>>
>>> Did anyone get into problems with the org.snmp4j.security.Salt class?
>>>
>>> Basically, I had no problems with SNMP4J on any platform until I tried
>>> to port my application to a Gentoo Linux box (Linux collector
>>> 2.6.9-gentoo-r13 #1 SMP Sat Jan 8 21:54:05 CET 2005 i686 Intel(R)
>>> Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux). Apparently, my JVM freezes
>>> somewhere in the Snmp() constructor. All JVM versions are affected (1.4,
>>> 1.5).
>>>
>>> I had a hard time trying to locate the "freezing point" in the SNMP4J
>>> source code. Well, I am quite sure that it happens on the next two lines
>>> of the Salt class:
>>>
>>> ...
>>> SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
>>> sr.nextBytes(rnd);   <------- THIS LINE FREEZES JVM
>>> ...
>>>
>>> Ok, it's easy to skip these two lines and force code to work. I am just
>>> curious why this happens. Any ideas?
>>>
>>> Greetings,
>>> Sasa Markovic.
>>>
>>> _______________________________________________
>>> SNMP4J mailing list
>>> SNMP4J at agentpp.org
>>> http://p15141779.pureserver.info/mailman/listinfo/snmp4j
> 
> 
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://p15141779.pureserver.info/mailman/listinfo/snmp4j