[
https://issues.apache.org/jira/browse/HDFS-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101653#comment-13101653
]
Eli Collins commented on HDFS-1835:
-----------------------------------
Shouldn't we make this change to DataNodeCluster and NNStorage as well? They're
not truly cryptographic uses as well. We should also factor this out to a
utility method, seems like the three uses are slightly different, eg one uses
DFSUtil.getRandom and the other creates a new Random object.
On a somewhat related note, a workaround for the blocking is to use urandom,
however according to this bug (http://bugs.sun.com/view_bug.do?bug_id=6202721)
setting securerandom.source to "/dev/urandom" doesn't actually work when using
SHA1PRNG.
> DataNode.setNewStorageID pulls entropy from /dev/random
> -------------------------------------------------------
>
> Key: HDFS-1835
> URL: https://issues.apache.org/jira/browse/HDFS-1835
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: data-node
> Affects Versions: 0.20.2
> Reporter: John Carrino
> Fix For: 0.23.0
>
> Attachments: DataNode.patch, hdfs-1835.txt
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> DataNode.setNewStorageID uses SecureRandom.getInstance("SHA1PRNG") which
> always pulls fresh entropy.
> It wouldn't be so bad if this were only the 120 bits needed by sha1, but the
> default impl of SecureRandom actually uses a BufferedInputStream around
> /dev/random and pulls 1024 bits of entropy for this one call.
> If you are on a system without much entropy coming in, this call can block
> and block others.
> Can we just change this to use "new
> SecureRandom().nextInt(Integer.MAX_VALUE)" instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
