Alix / Geode / Security Block support
-
Hi All,
I'm running a Alix2c3 (AMD Geode LX800/500Mhz) with pfsense 1.2 (embedded Alix/Wrap variant).
Now I wondered about the low OpenSSL performance and suspect that the security block
of the Geode CPU is not used at all by OpenSSL.OpenSSL> speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
To get the most accurate results, try to run this
program when this computer is idle.
Doing aes-128-cbc for 3s on 16 size blocks: 832833 aes-128-cbc's in 2.78s
Doing aes-128-cbc for 3s on 64 size blocks: 241807 aes-128-cbc's in 2.94s
Doing aes-128-cbc for 3s on 256 size blocks: 61012 aes-128-cbc's in 2.88s
Doing aes-128-cbc for 3s on 1024 size blocks: 15219 aes-128-cbc's in 2.86s
Doing aes-128-cbc for 3s on 8192 size blocks: 1964 aes-128-cbc's in 2.94s
OpenSSL 0.9.7e-p1 25 Oct 2004
built on: Thu Feb 21 18:09:17 EST 2008
options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)
compiler: cc
available timing options: USE_TOD HZ=128 [sysconf value]
timing function used: getrusage
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 4793.36k 5259.17k 5420.32k 5447.68k 5467.54kThe numbers are in the range of what we can expect from a unaccelerated execution.
The openssl version seems to be a bit outdated and the compiler line doesnt show
any special cryptdev support.Startup shows:
$ dmesg | grep -i crypt
pci0: <encrypt decrypt,="" entertainment="" crypto="">at device 1.2 (no driver attached)Is it possible to have a Geode security block enabled pfsense version for the Alix ?
Regards
Guido</encrypt> -
Does it work on a stock FreeBSD installation?
-
Will try when I have some more HW for a test.
-
Bugger…
...first udrive received was broken....will take some more time for a test.
-
I Installed a minimal FreeBSD 7 install on my test Alix 2C3. dmesg still shows no driver attached. It looks like OpenBSD has support via the glxsb driver, but there is currently no support in FreeBSD.
pciconf -lv shows:
none0@pci0:0:1:2: class=0x101000 card=0x20821022 chip=0x20821022 rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'GX3 Geode GX3 AES Crypto Driver'
class = encrypt/decryptedit- Testing with a vpn1411 shows the hifn driver is not loaded on a stock kernel, but this can be fixed by a quick 'kldload hifn'
-
There appears to be some recent work going on on porting the glxsb driver to FreeBSD;
http://thread.gmane.org/gmane.os.freebsd.devel.hackers/32879
I think we'll soon have a working driver. :)
-
Excellent. Now all we need is someone to figure out the LEDs and reset switch.
-
Re: adrian_m
thanks for pointing this out. Looks like he makes real good progress and is ready for some tests.
Unfortunatly my "new" uDrive has gone to the uDrive heaven as 2 others before :'(
Hope somebody else can pickup the sources and give it a try (FBSD 7.0 based)
-
Hi All,
I can confirm that the code from the above mentioned thread on freebsd-hackers@,
compiled correctly on an 6.2 machine (after patching with the included patch for 6.2).
Then I transferred the module on my Soekris Net5501-70 running pfSense 1.2 and
it seems to work correctly :uname -a
FreeBSD mars.XXX.net 6.2-RELEASE-p11 FreeBSD 6.2-RELEASE-p11 #0: Sun Feb 24 16:32:58 EST 2008 sullrich@builder6.pfsense.com:/usr/obj.pfSense/usr/src/sys/pfSense.6 i386dmesg | grep ^glxsb
glxsb0: <amd geode="" lx="" security="" block="" (aes-128-cbc,rng)="">mem 0xa0000000-0xa0003fff irq 10 at device 1.2 on pci0</amd> -
Decided to try this on my 1.3AA test box just for grins. I compiled glxsb.ko on a stock FreeBSD 7.0 box, then copied it to /boot/kernel, added glxsb_load="YES" to loader.conf
Made a cheap hack to /usr/local/www/index.php so I could see the crypto:Find out whether there's hardware encryption or not
unset($hwcrypto);
$fd = @fopen("{$g['varlog_path']}/dmesg.boot", "r");
if ($fd) {
while (!feof($fd)) {
$dmesgl = fgets($fd);
if (preg_match("/^(hifn|glxsb).: (.*?),/", $dmesgl, $matches)) {
$hwcrypto = $matches[[b]2];
break;
}
}
fclose($fd);
}Don't know when I'll have a chance to test- I'm not sure IPsec is even stable on the AlphaAlpha's
If you have a Hifn, you won't see it as the glxsb will show up first. Someone who can code might be able to sort that out, but that got me thinking- Will the glxsb be used by default for crypto even if you have a Hifn (which should be faster) installed?
-
I'm interested in using this for OpenVPN connections. It seems like it might be usable now, and just needs to be tested some more?
I don't have the hardware, but thinking of getting some soon.
Has anyone had success in testing this with OpenVPN? -
It is probably best seen as an experimental feature, especially until it's been checked into the FreeBSD repository. Hopefully that will happen before the FreeBSD 7.1 release process starts. As I don't follow freebsd-hackers, I'm not sure whether a committer has started working with the author to get this checked in.
-
I'm interested in using this for OpenVPN connections. It seems like it might be usable now, and just needs to be tested some more?
Yes, please test. I don't expect any problem.
I don't have the hardware, but thinking of getting some soon.
Has anyone had success in testing this with OpenVPN?I've tested it with openssl and ipsec. Any other test is welcome.
Regards.
-
Will the glxsb be used by default for crypto even if you have a Hifn (which should be faster) installed?
Yes. The crypto framework does not take care about the performance of the drivers. It selects the driver with the fewest active sessions.
If you have a hifn you should not use the glxsb driver, i think.
-
It is probably best seen as an experimental feature, especially until it's been checked into the FreeBSD repository. Hopefully that will happen before the FreeBSD 7.1 release process starts. As I don't follow freebsd-hackers, I'm not sure whether a committer has started working with the author to get this checked in.
Not yet, but I hope in one week or two :)
-
It is probably best seen as an experimental feature, especially until it's been checked into the FreeBSD repository. Hopefully that will happen before the FreeBSD 7.1 release process starts. As I don't follow freebsd-hackers, I'm not sure whether a committer has started working with the author to get this checked in.
Pawel Jakub Dawidek was going to review and commit the code, but his soekris box died. It appears the code is currently in limbo…
UPDATE: The glxsb driver is now in RELENG_7Yes. The crypto framework does not take care about the performance of the drivers. It selects the driver with the fewest active sessions.
If you have a hifn you should not use the glxsb driver, i think.
That would seem to be a problem with adding the driver to the stock kernel- if you had a VPN1411 in your Alix, using a kernel with glxsb in it could lower your crypto speed. Perhaps an option to load the module that would turn on glxsb_load="YES"
