2 Replies Latest reply on May 11, 2012 5:30 PM by atripathy86

    /dev/random produces no output at runtime on SCC Cores




      /dev/random does not seem to be producing any output on the SCC cores. We are using SccKit and the standard linux kernel. Has anyone faced this issue or does anyone know of a workaround? 


      Here's what we tried to test this out:

      cat /dev/random > temp


      ls -al temp

      -rw-------    1 user1   user1           0 Apr 26 14:25 temp


      On linux machines, it is supposed to create a finite size file

      -rw-r--r-- 1 user user 62 2012-05-08 19:55 temp


      My understanding is that /dev/random is a special file that serves as a random number generator by returning random bytes within the estimated number of bits of noise in the entropy pool. /dev/random is supposed to block until sufficient environmental noise is generated. It is therefore typically used in generating cryptographic keys. It also seems as per http://www.pinkas.net/PAPERS/gpr06.pdf that diskless clients may have trouble generating sufficient entropy because their state is predictable. Isn't that going to be true for the SCC cores? Is there some way to work around this? Am I missing something? Perhaps there is a way to enable the right flag during a SCCLinux build process? Does anyone know?


      We are trying to run some java code on the SCC cores which uses the sun.security.provider which in turn calls /dev/random and /dev/urandom (Line 255 - here). We have verified that it is blocking due to /dev/random.


      We also tried to check /dev/urandom. It is supposed to do the same thing except that it is supposed to be non-blocking. Happily that seems to work fine.


      cat /dev/urandom > temp4


      ls -al temp4

      -rw-------    1 user1   user1        2723 Apr 26 14:38 temp4

        • 1. Re: /dev/random produces no output at runtime on SCC Cores



          I was able to reproduce this issue on the latest sccKit 1.4.2. You are correct about /dev/random being the interface to the random number generator. If there is enough entropy in the kernel's pool, it returns random data; otherwise, it blocks until the pool has been filled again. Unfortunately there is no "real" workaround for missing entropy; after all, computers are deterministic (at least we hope so ), so they cannot generate "random" data if there is no source of white noise.


          As for the issue with /dev/random, we can cheat. If you do not need real random data and are fine with what /dev/urandom produces, you can just use that. I'd think this is the preferred method, because it makes clear (in the application's configuration, or maybe even its source code) that it uses pseudo-random data.


          If this is not possible, e.g. because you cannot recompile, you can still redirect /dev/random to /dev/urandom. I tried two methods, and both of them worked:


          1. "rm /dev/random", then "ln -s /dev/urandom /dev/random". That should make all applications referring /dev/random to use /dev/urandom instead. However, applications can detect this change (e.g., because "random" is now a symbolic link, not a device node), and it would not help for programs creating their own "random" device node (whose major and minor function numbers are well-known).
          2. Install rng-tools on the SCC cores (in the buildroot directory, make menuconfig, Package Selection for Target, Hardware Handling, rng-tools; recompile), then start "rngd --rng-device=/dev/urandom". That fills the kernel's entropy pool with data from /dev/urandom, so you can now read /dev/random without ever having to wait again.


          Inevitable disclaimer: Please note that, in both cases, data read from /dev/random is now only as good as /dev/urandom; i.e., pseudo-random and predictable. Using such data is strongly discouraged for any security-sensitive work. You can still use it to generate keys, but I suggest never to use such keys outside of a lab environment.


          Last but not least, there is also a method for inserting real entropy into the pool that does not require such tricks: connect to the SCC core using sccDisplay (sccGui must be closed first), then work a bit from that console session. The emulated keyboard and mouse produce entropy that can be read using the default /dev/random.