Is the glxsb device's hardware RNG being utilized?
-
Hi,
I have an Alix 2D2 with the AMD Geode LX800 cpu. I'm running 1.2.3-RELEASE embedded on a 2gig CF. I was wondering, I see this in the dmesg:
glxsb0: <amd geode="" lx="" security="" block="" (aes-128-cbc,="" rng)="">mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0
I see that this provides AES processing and RNG which I'm assuming means Random Number Generator.
The system comes up fine and my ipsec tunnel (using AES-128) comes up without issue. Today I did a dmesg on my system that has been running for over 7 days, and I noticed this at the bottom of the dmesg output:
WARNING: pseudo-random number generator used for IPsec processing
If the geode has a built in hardware random number generator and the glxsb0: device is loaded (shows up in kldstat) why is it using the software RNG? I'm pretty sure when the system first booted up, and the first time the IPSec tunnel came up, this warning was not there. Is it possible that after the IPSec SAs time out (I have it set to 28800 seconds ala cisco) that it's failing to access the hardware RNG for some reason?
Is there a way for me to get some more information about whether racoon is utilizing the glxsb device?
Please advise, thanks in advance.</amd>
-
If your tunnel is set to Rijndael (AES) it should use the accelerator. If you have any doubt, run a load test on the tunnel with glxsb enabled and disabled (there is a checkbox under advanced options).
http://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported
Some of the software RNG may be for other incidental things being used which are not supported by glxsb. Unfortunately I'm not sure there is any way to get details out of that error.
-
OK Thanks for the reply. I will take a look at doing some benchmarks.
I did some more research and I guess the kernel can choose to use the Software RNG if the hardware one is busy. Seems logical I guess, but since the software one is not as "random" as the hardware RNG, you would think the developers would opt to wait for the hardware to be available again. I also read that there are some ipsec-tools that can be installed which help determine what's going on under the hood, but I'm not looking to modify my pfsense install at this point. I'm sure 2.0, which is based on FreeBSD 8, will have a newer version of the glxsb driver and all that, so perhaps that will utilize the glxsb more. I do use Rijndael for the IPSec tunnel to my colo. I was just hoping that there was some sort of easy way to verify that IPSec or opencrypto is actually bound to the glxsb device. One other thing that worries me is that since glxsb is loaded as a module, it's actually loaded after the ipsec support for the kernel is. I just hope that it sees that the new hardware is available after it has been initialized.
another interesting tidbit:
[1.2.3-RELEASE] [root@router]/var/log(23): sysctl -a | grep crypto
<118>(cryptodev) BSD cryptodev engine
<118>engine "cryptodev" set.
<118>openssl speed -evp aes-128-cbc -elapsed -engine cryptodev
<118>cryptosoft0: <software crypto="">on motherboard
<118>pci0: <encrypt decrypt,="" entertainment="" crypto="">at device 1.2 (no driver attached)
<118><118>(cryptodev) BSD cryptodev engine
<118><118>engine "cryptodev" set.
<118><118>openssl speed -evp aes-128-cbc -elapsed -engine cryptodev
<118><118>cryptosoft0: <software crypto="">on motherboard
<118><118>pci0: <encrypt decrypt,="" entertainment="" crypto="">at device 1.2 (no driver attached)
<118>kern.cryptodevallowsoft: 0
<118>kern.userasymcrypto: 1
<118>net.inet.ipsec.crypto_support: 50331648
<118>debug.crypto_timing: 0
<118>dev.cryptosoft.0.%desc: software crypto
<118>dev.cryptosoft.0.%driver: cryptosoft
<118>dev.cryptosoft.0.%parent: nexus0
<118>cryptosoft0: <software crypto="">on motherboard
<118>pci0: <encrypt decrypt,="" entertainment="" crypto="">at device 1.2 (no driver attached)vr0: <via 10="" vt6105m="" rhine="" iii="" 100basetx="">0
<118>(cryptodev) BSD cryptodev engine
*kern.cryptodevallowsoft: 0
kern.userasymcrypto: 1
net.inet.ipsec.crypto_support: 50331648
debug.crypto_timing: 0
dev.cryptosoft.0.%desc: software crypto
dev.cryptosoft.0.%driver: cryptosoft
dev.cryptosoft.0.%parent: nexus0It seems like software crypto is specifically turned off in the sysctl controls. Anyway, just some stuff to tinker with :P</via></encrypt></software></encrypt></software></encrypt></software>
