This is self-documentary as opposed to a precise how-to, if in doubt do your own research and due diligence, I had to !
Marvell kirkwood arm5 processor in my GoFlex Net has a HARDWARE cryptography co-processor. And basically from what I can understand it lies idle whilst encryption/decryption is done in the CPU. This makes the box slower and perform worse.
A solution - cryptodev-linux PLUS openssl compiled to use the cryptodev library and therefore the build in hardware co-processor.
Easy, no it wasn't, I've been at this for nearly a week.
Before you begin
cryptodev is a project maintained by Nikos Mavrogiannopoulos - http://cryptodev-linux.org
It would be nice to see cryptodev-linux as a mainstream package in Debian, but this is above and beyond my capbilities. So we'll need to compile and set it up ourselves.
openssl is the defacto decryption/encryption library used just about everywhere on linux for just about everything. Without recompiling it, it won't be default use the hardware encryption co-processor.
SO, in order to get hardware cryptography up and running, we first need to install cryptodev, and then a patched version of openssl. There maybe other software which takes advantage of cryptodev engine, I'm not a linux expert so I don't know :D
NB. This was a very long process, I'm writing a lot memory, may have missed a step or two. OFTEN/usually Debian tells you of missing packages etc, so install them if what you're doing depends on them ... etc ...
Turning GoFlex Net Into A Ferrari :)
cryptodev
First off I tried to compile 1.6 of cryptodev, it didn't work. So I got it from their git repositoty instead. Along these lines :
That should be cryptodev installed ( or mostly installed ) ... adding modules so kernel knows about them isn't my strong suit, so I think this is how it's done :
Arch linux seems to think this is needed - http://archlinuxarm.org/forum/viewtopic.php?t=2452
If anyone can tell me which is/isn't correct or both, I'll edit later :D
You can list the cryptodev module with either :
Also my dmesg has a message to tell me cryptodev has been loaded -
My cryptodev kernel module lives here :
So hopefully you should now have cryptodev installed ... phew !
openssl
Now this was a real BITCH to install. Partly I'm not a C++/Make/Linux expert and partly, well looking at 15 different versions of a piece of code etc etc etc ... anyway I persevered and eventually saw this :
The problem seems to be openssl aren't maintaining the crytodev aspect of openssl properly and haven't included Nikos's patches in their code. Add to this that Nikos's patches wouldn't patch the openssl code, and it get's confusing. So I've just attached the eng_cryptodev.c you'll need, already patched. It's the best of various versions, and compiles and works on my machine. It's based on the eng_cryptodev.c from cryptodev-linux release 1.6 from the "extras" folder.
So, down to the easy stuff (ref - https://wiki.debian.org/SourcePackage)
Get my patched eng_cryptodev.c at the ready :D
Job done if I remember correctly, hopefully have missed too many steps !
Questions
I've said a few times, I'm not a Linux/C++/Hardware expert, just persistent mostly. I wasn't sure whether to include the "shared threads" argument - does anyone know what this does and whether it's needed/helpful ?
It doesn't appear to affect the overall operation ! ... and it seems there isn't a libcryptodev, or at least I could find one or a way to make one :D
ALSO the -DHASH_MAX_LEN=64 flag has been included from what I understand because the hardware cryptography engine works better on smaller hashes and gets slower on larger hashes. HOWEVER my question is this, wouldn't it be better overall on the machine to be offloading ALL of the cryptography, so the rest of the CPU is available for other work ?
Complaints to /dev/null ... Questions and comments welcome, provided you can string a polite and relevant sentence together :D
Cheers
DC
PS I'm running a bodhi 3.15 tld 3 kernel, Debian Wheezy, GoFlex Net
Marvell kirkwood arm5 processor in my GoFlex Net has a HARDWARE cryptography co-processor. And basically from what I can understand it lies idle whilst encryption/decryption is done in the CPU. This makes the box slower and perform worse.
A solution - cryptodev-linux PLUS openssl compiled to use the cryptodev library and therefore the build in hardware co-processor.
Easy, no it wasn't, I've been at this for nearly a week.
Before you begin
cryptodev is a project maintained by Nikos Mavrogiannopoulos - http://cryptodev-linux.org
It would be nice to see cryptodev-linux as a mainstream package in Debian, but this is above and beyond my capbilities. So we'll need to compile and set it up ourselves.
openssl is the defacto decryption/encryption library used just about everywhere on linux for just about everything. Without recompiling it, it won't be default use the hardware encryption co-processor.
SO, in order to get hardware cryptography up and running, we first need to install cryptodev, and then a patched version of openssl. There maybe other software which takes advantage of cryptodev engine, I'm not a linux expert so I don't know :D
NB. This was a very long process, I'm writing a lot memory, may have missed a step or two. OFTEN/usually Debian tells you of missing packages etc, so install them if what you're doing depends on them ... etc ...
Turning GoFlex Net Into A Ferrari :)
cryptodev
First off I tried to compile 1.6 of cryptodev, it didn't work. So I got it from their git repositoty instead. Along these lines :
# a couple of benchmarks, records the results and do these after you've installed openssl speed -evp aes-128-cbc openssl speed -evp sha1 # may be some others here like build-essential and make, I forget exactly which ! apt-get install git cd /home mkdir cryptodev cd cryptodev git clone https://github.com/cryptodev-linux/cryptodev-linux cd cryptodev-linux # refer to file INSTALL make make install # If alls well then run this to check alls well make check
That should be cryptodev installed ( or mostly installed ) ... adding modules so kernel knows about them isn't my strong suit, so I think this is how it's done :
echo "cryptodev" >> /etc/modules
Arch linux seems to think this is needed - http://archlinuxarm.org/forum/viewtopic.php?t=2452
# make cryptodev load at boot -> edit /etc/rc.conf MODULES=(cryptodev) # and .... echo 'KERNEL=="crypto", MODE="0666"' > /etc/udev/rules.d/99-cryptodev.rules # and .... echo "cryptodev" > /etc/modules-load.d/cryptodev.conf
If anyone can tell me which is/isn't correct or both, I'll edit later :D
You can list the cryptodev module with either :
cat /proc/modules or lsmod # AND you should have this : ls /dev/crypto
Also my dmesg has a message to tell me cryptodev has been loaded -
dmesg | grep cryptodev [ 34.832269] cryptodev: driver 1.6 loaded.
My cryptodev kernel module lives here :
ls -l /lib/modules/3.16.0-kirkwood-tld-3/extra total 48 -rw-r--r-- 1 root root 46752 Oct 18 09:06 cryptodev.ko
So hopefully you should now have cryptodev installed ... phew !
openssl
Now this was a real BITCH to install. Partly I'm not a C++/Make/Linux expert and partly, well looking at 15 different versions of a piece of code etc etc etc ... anyway I persevered and eventually saw this :
openssl engine cryptodev (cryptodev) cryptodev engine
The problem seems to be openssl aren't maintaining the crytodev aspect of openssl properly and haven't included Nikos's patches in their code. Add to this that Nikos's patches wouldn't patch the openssl code, and it get's confusing. So I've just attached the eng_cryptodev.c you'll need, already patched. It's the best of various versions, and compiles and works on my machine. It's based on the eng_cryptodev.c from cryptodev-linux release 1.6 from the "extras" folder.
So, down to the easy stuff (ref - https://wiki.debian.org/SourcePackage)
Get my patched eng_cryptodev.c at the ready :D
cd /home mkdir openssl cd openssl # this will get openssl-1.0.1e # you need to have the deb-src lines in your /etc/apt/sources.list apt-get source openssl cd openssl-1.0.1e # YOU NEED TO NOW PUT MY eng_cryptodev in the ./crypto/engine/ folder # YOU WILL ALSO NEED TO EDIT ./debian/rules , and edit the CONFARGS variable like so : vi ./debian/rules CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 shared threads zlib enable-tlsext no-ssl2 # I'm not sure if editting the CONFARGS is 100% neccessary, but I couldn't find out what "shared threads" means # and ArchLinux suggest that it's needed. So I figured it is needed. # Build/Compile/Package DEB_CFLAGS_APPEND='-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64' dpkg-buildpackage -b -us # if all goes well the parent directory will contain deb packages to install cd .. # Not sure if all these steps are neccessary, you might just need openssl, but be on safe side dpkg -i libssl1.0.0_1.0.1e-2+deb7u13_armel.deb dpkg -i libssl-doc_1.0.1e-2+deb7u13_all.deb dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u13_armel.deb dpkg -i libssl-dev_1.0.1e-2+deb7u13_armel.deb dpkg -i openssl_1.0.1e-2+deb7u13_armel.deb # With any luck, and some prayers, try this : openssl engine cryptodev #And you should see this : (cryptodev) cryptodev engine # If all's well then you can run the tests you did at the begining to verify cryptodev actually using hardware openssl speed -evp aes-128-cbc openssl speed -evp sha1
Job done if I remember correctly, hopefully have missed too many steps !
Questions
I've said a few times, I'm not a Linux/C++/Hardware expert, just persistent mostly. I wasn't sure whether to include the "shared threads" argument - does anyone know what this does and whether it's needed/helpful ?
It doesn't appear to affect the overall operation ! ... and it seems there isn't a libcryptodev, or at least I could find one or a way to make one :D
ALSO the -DHASH_MAX_LEN=64 flag has been included from what I understand because the hardware cryptography engine works better on smaller hashes and gets slower on larger hashes. HOWEVER my question is this, wouldn't it be better overall on the machine to be offloading ALL of the cryptography, so the rest of the CPU is available for other work ?
Complaints to /dev/null ... Questions and comments welcome, provided you can string a polite and relevant sentence together :D
Cheers
DC
PS I'm running a bodhi 3.15 tld 3 kernel, Debian Wheezy, GoFlex Net