Hardware Cryptography for Kirkwood

Guides written by the community, for the community, and only guides!

Re: Hardware Cryptography for Kirkwood

Postby kmihelich » Thu Mar 01, 2012 4:53 am

The kernel for Kirkwood devices has been updated to 3.1.10-4, which includes the cryptodev module. The package openssl-cryptodev is also in the repos, which will replace openssl when you install it. Let me know how all this works.
Arch Linux ARM exists and continues to grow through community support, please donate today!
kmihelich
Developer
 
Posts: 1133
Joined: Tue Jul 20, 2010 6:55 am
Location: aka leming #archlinuxarm

Re: Hardware Cryptography for Kirkwood

Postby Kurlon » Thu Mar 01, 2012 5:16 am

Installed cleanly on my GFN, I forgot to check if a udev rule was being added given that I already had one in place though.
Kurlon
 
Posts: 132
Joined: Fri Jan 06, 2012 10:05 pm

Re: Hardware Cryptography for Kirkwood

Postby kmihelich » Thu Mar 01, 2012 5:33 am

I didn't add in any udev rules to either of the packages, though I certainly can. The openssl-cryptodev package would likely be the best candidate for using them.

If everything tests fine by all of you here, I'll get it rolled into the next rootfs tarball. I've been holding back on creating a new one to see how all this shapes up.
Arch Linux ARM exists and continues to grow through community support, please donate today!
kmihelich
Developer
 
Posts: 1133
Joined: Tue Jul 20, 2010 6:55 am
Location: aka leming #archlinuxarm

Re: Hardware Cryptography for Kirkwood

Postby pepedog » Thu Mar 01, 2012 9:51 am

Nice.
Running Pogo V2, added udev rule and modprobe cryptodev
$this->bbcode_second_pass_code('', '[root@alarm2 ~]# openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 82488 aes-128-cbc's in 0.06s
Doing aes-128-cbc for 3s on 64 size blocks: 80211 aes-128-cbc's in 0.06s
Doing aes-128-cbc for 3s on 256 size blocks: 39115 aes-128-cbc's in 0.06s
Doing aes-128-cbc for 3s on 1024 size blocks: 39966 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 8192 size blocks: 8102 aes-128-cbc's in 0.03s')
Think CuBox has cryptographic engine http://www.marvell.com/application-proc ... rmada-500/ and has kernel 2.6.32.9 but is being ported to 3.x
Webmin, including file manager, flies like a rocket
pepedog
Developer
 
Posts: 2431
Joined: Mon Jun 07, 2010 3:30 pm
Location: London UK

Re: Hardware Cryptography for Kirkwood

Postby devr » Thu Mar 01, 2012 12:38 pm

Installed the 3.1 kernel (previously had been at 3.2) & openssl-crypto. Tested the openssl segfault when dealing with Certs, the aes-128-cbc perf test, and that nginx+openssl does not error out with https negotiation offloading. I manually added the udev rule, and permissions are perfect after a reboot.

Thank you for your time & effort in updating these packages.

EDIT: FYI this was tested on a TonidoPlug2 w/ Feroceon 88FR131 rev 1 (v5l) cpu.
devr
 
Posts: 87
Joined: Wed May 11, 2011 12:22 am

Re: Hardware Cryptography for Kirkwood

Postby pklaus » Thu Mar 01, 2012 5:02 pm

Hi! I tested your recent changes of the hardware crypto support on my GoFlex Home.

(Just for those who are joining this thread like me, theses were my complete steps to enable it:)
$this->bbcode_second_pass_code('', 'pacman -Syyuf
pacman -S openssl-cryptodev
echo '"KERNEL=="crypto", MODE="0666"' > /etc/udev/rules.d/99-cryptodev.rules
# Add cryptodev to the MODULES in /etc/rc.conf or manually load it after each new boot:
modprobe cryptodev
# probably not needed:
reboot
')

I could see a speedup of the OpenSSL benchmark. The logs are on https://gist.github.com/1950517 .

I was trying to also compare real world md5 hash calculation as well (md5sum filename versus openssl dgst -md5 filename).
First OpenSSL crashed when calculating the MD5 hash of a large file (larger than my RAM - message was openssl invoked oom-killer). So it seems that OpenSSL tries to load the whole file into the memory which is only ~120MiB on my GoFlex Home. The md5sum could calculate the hash without problems. Anyway, with a smaller file (70MiB) the openssl command took ~1.5 seconds to complete and the md5sum command only ~0.7s.

When transfering large files over a tunnel created via ssh I can get a decent speedup / less system load using the option -c aes256-cbc (which makes use of the hardware crypto module as the load on the mv_crypto kernel thread indicates).

Great work!
pklaus
 
Posts: 15
Joined: Sat Apr 30, 2011 4:25 pm

Re: Hardware Cryptography for Kirkwood

Postby Kurlon » Thu Mar 01, 2012 5:12 pm

Interesting to see crypto reports hardware LZO support. I wonder if zram utilizes that at all?
Kurlon
 
Posts: 132
Joined: Fri Jan 06, 2012 10:05 pm

Re: Hardware Cryptography for Kirkwood

Postby WarheadsSE » Thu Mar 01, 2012 5:32 pm

Looks like MD5 is using the generic module, but then magically smashing the hell out of something at 8K blocks. The actual crypto though, nice improvement.
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6807
Joined: Mon Oct 18, 2010 2:12 pm

Re: Hardware Cryptography for Kirkwood

Postby pklaus » Sat Mar 03, 2012 11:08 am

$this->bbcode_second_pass_quote('Kurlon', 'I')nteresting to see crypto reports hardware LZO support. I wonder if zram utilizes that at all?

Actually I don't think LZO is being hardware accelerated. The output of /proc/crypto concerning lzo reports it to be operated using driver : lzo-generic and module : kernel. If I interpret it correctly this means it's being software calculated by the kernel.

$this->bbcode_second_pass_quote('WarheadsSE', 'L')ooks like MD5 is using the generic module, but then magically smashing the hell out of something at 8K blocks. The actual crypto though, nice improvement.


I would think the MD5 is definitely being hardware accelerated although it's rather being "hardware slowed down" (still less CPU load though). Probably the /proc/crypto output of the kernel concerning MD5 is just tricking us to think the kernel would do it in software...

After all I don't know enough about the current crypto architecture in the kernel.
For example: What's the difference between mv_cesa and mv_crypto. Is cryptodev an alternative to some kine of kernel hardware crypto support? And what has /proc/crypto to do with it?
From what I think to understand, programs need to be patched against cryptodev (/dev/crypto) support. Would this be different if they used the kernel for - let's say AES encryption (in case the kernel had hardware crypto support)?

Anyway... I'm really happy that OpenSSL, OpenSSH (using OpenSSL), OpenVPN (using OpenSSL) etc. have a decent hardware crypto support now.
Thanks for the good work! Keep it up!
pklaus
 
Posts: 15
Joined: Sat Apr 30, 2011 4:25 pm

Re: Hardware Cryptography for Kirkwood

Postby firefoxPL » Wed Mar 07, 2012 6:58 pm

Hi, I've updated my original post to include pacman installation procedure. I've just updated everything on my pogo but somehow I still get the same old error while trying to create a CA certificates for OpenVPN, maybe I'll just create a fresh install and see how it goes then. Could anyone check if OpenVPN build-ca and other scripts work with openssl and cryptodev?
Pogo-P24 (new Pogoplug Classic) - ALARM on SATA (mediatomb, netatalk, avahi, time machine, swap, openvpn)
Pogo-E02 (v2 Pink) - ALARM on USB (netatalk, avahi, cryptodev-linux, getting ready for L2TP)
firefoxPL
 
Posts: 65
Joined: Thu Dec 08, 2011 1:49 pm

PreviousNext

Return to Community Guides

Who is online

Users browsing this forum: No registered users and 6 guests