Alix / Geode / Security Block support

gidi

Will try when I have some more HW for a test.

gidi

Bugger…

...first udrive received was broken....will take some more time for a test.

dotdash

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/decrypt

edit- 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'

adrian_m

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. :)

dotdash

Excellent. Now all we need is someone to figure out the LEDs and reset switch.

gidi

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)

ndenev

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 i386

dmesg | grep ^glxsb
glxsb0: <amd geode="" lx="" security="" block="" (aes-128-cbc,rng)="">mem 0xa0000000-0xa0003fff irq 10 at device 1.2 on pci0</amd>

dotdash

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?

glxsb.jpg_thumb

adrian_m

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?

David_W

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.

plamaiziere

@adrian_m:

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.

plamaiziere

@dotdash:

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.

plamaiziere

@David_W:

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 :)

dotdash

@David_W:

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_7

@plamaiziere:

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.

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"