AllHands
|
both friday and saturday : planning, cleaning, breaking, moving, throwing all the dirt that's piled up in the new space..
friday nobody was there to help clean up, and i don't need a good excuse to loose myself (and my evening/night) into messing around with computers: goal of tonight: making use of the padlock hardware crypto in ssh (tazo bought over one of the via c7 boards i found a month ago on the fleemarket) - as it will be a node in dn42 (openvpn) and be heavily used for ssh & scp etc.
VIA padlock hw crypto support[edit]
padlock_aes & padlock_hash kernel modules, - those are included in the openwrt distrib, they are useful for crypto operations in kernel space (crypted harddisk/partition, IPSEC,..) but it won't help the processor hogging by the userspace programs & daemons (scp'ing those debian dvd bringing the whole box on it's knees). so :
OpenSSH (ssh-daemon, client, scp, sftp) counts on the OpenSSL library (libcrypto) for it's cryptographic operations; so OpenSSL is a good place to start looking for crypto-hardware support...
as the box has limited amount of flash-storage we take our distro-of-choice : OpenWRT; as said before kernel modules are nicely selectable and work without trouble; the adventure starts when we go userspace, in the dungeons of ssl
openssl[edit]
the openssl package sets some configuration flags that disable hw-crypto -- as for now I just edited the package Makefile (cfr package/openssl/Makefile) to reflect our needs.
- delete the no-hw configure parameter
- change the patch that prevents the 'engines' subfolder to be compiled (engines are 'openssl-speak' for dynamically loadable crypto implementations; the one we want specifically is libpadlock.so
after compiling & installing this fresh package,
openssl engine -c -tt
should show the VIA padlock & all ciphers this baby can churn out
we can now have a quick speedtest to keep motivated about this whole mumbojumbo
openssl speed -evp aes-128-cbc
- the CPU-only version
openssl speed -evp aes-128-cbc -engine padlock
- the padlock at work; in my case it showed a 4x to 5x speedup -- that's worth some hours of lost sleep & grey hair;
our next todo is edit the openssl configuration file, to select the padlock engine by default (instead of the 'built-in' default implementation, which calculates all on the CPU)
now this was already a bit involved, be ready for some hoops
openssh[edit]
openssh uses the openssl library for it's lowlevel crypto operations, but alas you need to compile it with the non-default configuration parameter '--with-ssl-engine' to be able to play with the hw-crypto 'engines'; so there we go for a quick change to the makefile (first use the feeds script to install openssh, then you'll find Makefile etc in feeds/package/net/openssh/. alas, this gave us _no result to speak of... the configure script nicely checks the availability of openssl & it's dynamic engines, but doesn't actually interact on the sourcecode (not in a meaningfull matter anyway) So i did something quite ugly, make a diff/patch of the sourcefiles we need to change; this because all executables seem to be lacking the initialisation function calls to start loading the OpenSSL dynamic engines.
After this patch the ssh executables will use the padlock crypto for supported ciphers (eg aes128-cbc or aes256-cbc) this gave doubled the throughput on the box (scp'ing a big file went 5.3 MByte/s at 100% cpu before the hw-crypto, to 11.3 MByte/s at 88% cpu, actually probably maxing out our ethernet interface)
