Double the speed of your Banana Pi!

3 2823
Just kidding!

Well maybe exagerating a bit.

The full story is at ... enerator-banana-pi/ it is unavoidably long.

The short version is I have compiled up a patch to the sunxi_ss crypto module that exposes it's hardware random number generator.  The compiled module and links to the various resources are in the blog post, including the maintainers site who wrote the patch.   It is more than twice as fast compared to /dev/urandom and as far as I can tell produces good random numbers.  In the real world it will allow apps that need lots of entropy to obtain it for a far smaller resource cost than they can now.

If you have the latest banaian, have the 4.4.26 kernel, then you can download it and have a play yourself.

Patch does not apply cleanly to the kernel source, fortuately, it only the Konfig change that doesn't work and that was easy to bodge and isn't material to the crytpto code, which did apply cleanly.

Small update the module author has indicated this will be going into the mainline kernel shortly, so all A20 based boards will soon have available a fast hardware RNG in the mainline kernel, which is nice addition.

Edited by ravermeister at Dec 06, 2016 11:20

...and here it is for the kernel 4.4.34

it is really faster (I tried your C snippets too ), but doesnt't it require that all running Daemons/Applications are using the new /dev/hwrng device? Or is it managed by the kernel that all Random numbers are now generated from this module/device?

have you compared the times of the boot process for example?

I'll have to compile up the 4.4.35 kernel now!

I have not done much so far, under normal circumstances I don't expect to see any performance increase.   It would most sensibly be used to simply seed the random number generator, rather than use it directly.  If however someone needed lots of random numbers quickly then this is a good option, but they are almost certainly writing code and hence have no problem accessing the device file directly and in that use case it would be well worth the effort.   

One obvious place where lots random numbers are used in with SSL for HTTPS and it was something I intended to explore.   Apache for example can specify an SSLCryptoDevice which potentially could be mapped onto the hardware random number generator.   This would free up some processing to service web requests so making the maximum number of SSL requests performantly supportable higher.    However there is probably a bigger performance kick from ensuring the hardware ciphers are preferred.   Something else I'll have a look at.

Java is another example where it could easily be used and might again depending upon circumstance show a big performance jump.  Java, in unix anyway, uses /dev/random, I have been bitten by this as it will block if there is insufficient entropy.   The answer is easy though switch to /dev/urandom, which never does, however here we could use /dev/hwrnd for a performance increase.  That said I doubt much java is running on a banana pi's!

You have to log in before you can reply Login | Sign Up

Points Rules