SSL/AES acceleration in FreeBSD ?

[John Case]

This presentation document from meetBSD 2008:

http://www.paeps.cx/pubs/crypto_acceleration/slides.pdf

lists these supported devices:

glxsb(4)  AMD Geode
hifn(4)  Hifn
padlock(4)  VIA Padlock
safe(4)  SafeNet
ubsec(4)  Broadcom/Bluesteel

However, I can only find "safe" as a isted device in generic kernel
configuration files.  The other devices are not anywhere in kernel config
files.

I am able to find hifn.ko and /sys/modules/padlock and ubsec.ko in the
source tree, however.

glxsb, however, is nowhere to be found.

My goal is to accelerate the Tor onion router using hardware on FreeBSD.
Since safe(4) is a standard kernel config option, that seemed a likely
starting place, however a cursory search shows that this is not really a
working device and certainly not a trouble-free item to implement.

Are any implementations of hardware crypto acceleration both stable and
trouble-free in FreeBSD ?

I appreciate all comments and suggestions.
_______________________________________________
freebsd-hardware@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@..."

[Steve Polyack]

John Case wrote:

>
> This presentation document from meetBSD 2008:
>
> http://www.paeps.cx/pubs/crypto_acceleration/slides.pdf
>
> lists these supported devices:
>
> glxsb(4)  AMD Geode
> hifn(4)  Hifn
> padlock(4)  VIA Padlock
> safe(4)  SafeNet
> ubsec(4)  Broadcom/Bluesteel
>
> However, I can only find "safe" as a isted device in generic kernel
> configuration files.  The other devices are not anywhere in kernel
> config files.  cd
>

I can personally verify FreeBSD's support for the Geode (glxsb(4)) and
various hifn(4) and ubsec(4) devices.  The code is all there and has
been there for some time:
glxsb(4) - /usr/src/sys/dev/glxsb
hifn(4) - /usr/src/sys/dev/hifn
ubsec(4) - /usr/src/sys/dev/ubsec

I'm not sure about the kernel options, but all of the above are
typically built as modules with the GENERIC kernel.  After loading the
module, the devices are then made available through the cryptodev(4)
driver.  OpenSSL and several tools
(/usr/src/tools/tools/crypto/cryptotest & cryptostats) can confirm they
are being used.

>
> My goal is to accelerate the Tor onion router using hardware on
> FreeBSD. Since safe(4) is a standard kernel config option, that seemed
> a likely starting place, however a cursory search shows that this is
> not really a working device and certainly not a trouble-free item to
> implement.

You will may find that for any fairly modern dual-core CPU (even an
Athlon64 X2), the CPU will outperform pretty much all of the hardware
crypto-accelerator offerings, except for the most recent and high-end.  
This is *especially* true when you are doing many small cryptographic
operations, which I assume Tor may be doing.  You'll still at least get
the benefit of offloading all of these operations from the CPU, freeing
it up to spend time on other tasks.
>
> Are any implementations of hardware crypto acceleration both stable
> and trouble-free in FreeBSD ?
In the testing I've done, the hifn, ubsec, and glxsb devices all work
quite well.  I haven't seen any problems with any of them.  If you're
still looking to select a card, I'd recommend the newest Broadcom
offerings that you can find on eBay at a fair price - these use the
ubsec(4) driver.
>
> I appreciate all comments and suggestions.
> _______________________________________________
> freebsd-hardware@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
> To unsubscribe, send any mail to
> "freebsd-hardware-unsubscribe@..."
>


_______________________________________________
freebsd-hardware@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@..."

[Dean Hamstead-2]

> You will may find that for any fairly modern dual-core CPU (even an
> Athlon64 X2), the CPU will outperform pretty much all of the hardware
> crypto-accelerator offerings, except for the most recent and high-end.  
> This is *especially* true when you are doing many small cryptographic
> operations, which I assume Tor may be doing.  You'll still at least get
> the benefit of offloading all of these operations from the CPU, freeing
> it up to spend time on other tasks.

this website gives more details confirming this statement.

http://sslacceleration.info/64bit.shtml

Interestingly, GMP benchmarking puts the Athlon64 significantly ahead of
the intel offerings (i7 being one of them) for complex math. Although
one must consider that the compilers are different versions etc.

http://gmplib.org/gmpbench.html

Certainly, given the low cost of the amd64 chips. For a CPU bound task
like SSL Acceleration, it would be interesting to see what the best bang
for buck would be in a cluster.


Dean
_______________________________________________
freebsd-hardware@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@..."