Hardware Crypto acceleration?

Jacob Appelbaum jacob at appelbaum.net
Sun Feb 14 02:25:36 UTC 2010


Hi,

I've been playing around with a VPN1401 PCI card[0]. This card ships
with the the Hi/Fn 7955 chipset (or is it properly called a hifn 7955?).

I want to use it to offload AES and SHA computation. Additionally, I
want it to seed my software random number generator. I specifically want
to ensure that Tor doesn't drain the entropy pool on my machine.

I have Tor configured as a normal client and I have added one line to my
torrc file:
HardwareAccel 1

I don't have any dynamic engines enabled (AccelName is unset). I'm not
sure what dynamic engines I might need. I think there are patches to
make this possible [1] but I've not used them.

When I start Tor with debug level logging, I see the relevant following
events:
Feb 13 18:04:04.681 [info] crypto_global_init(): Initializing OpenSSL
engine support.
Feb 13 18:04:04.681 [info] Using default implementation for RSA
Feb 13 18:04:04.681 [info] Using default implementation for DH
Feb 13 18:04:04.681 [info] Using default implementation for RAND
Feb 13 18:04:04.681 [info] Using default implementation for SHA1
Feb 13 18:04:04.681 [info] Using default implementation for 3DES
Feb 13 18:04:04.681 [info] Using default implementation for AES
Feb 13 18:04:04.681 [info] crypto_seed_rng(): Seeding RNG from
"/dev/urandom"

I'm running a Debian Lenny (current Stable) machine for my tests. It
appears to work out of the box for some software (eg: kernel CryptoAPI)
but I don't think it's working for Tor. I had to install the 'rng-utils'
package to feed the hardware RNG into my entropy pool. It appears to be
seeding my random number generator and so half of my requirements are
resolved.

Any idea on how to get OpenSSL to use this hardware for AES and SHA
acceleration?

Here are the relevant lines in my dmesg log from the kernel module loading:
[   19.819528] hifn795x: assuming 66MHz clock speed, override with
hifn_pll_ref=ext<frequency>
[   20.032612] hifn0: AES 128 ECB test has been successfully passed.
[   20.036288] Driver for HIFN 795x crypto accelerator chip has been
successfully registered.

Here are the relevant modules:
$ lsmod|grep hifn
hifn_795x              23812  0
rng_core                8968  2 hifn_795x
des_generic            21376  1 hifn_795x
crypto_blkcipher       21636  6 ecb,hifn_795x,cbc,dm_crypt

Here's what /proc/crypto reports:
~$ cat /proc/crypto
name         : ecb(arc4)
driver       : ecb(arc4-generic)
module       : ecb
priority     : 0
refcnt       : 3
type         : blkcipher
blocksize    : 1
min keysize  : 1
max keysize  : 256
ivsize       : 0
geniv        : <default>

name         : arc4
driver       : arc4-generic
module       : arc4
priority     : 0
refcnt       : 3
type         : cipher
blocksize    : 1
min keysize  : 1
max keysize  : 256

name         : ofb(aes)
driver       : hifn-aes
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>

name         : cfb(aes)
driver       : hifn-aes
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>

name         : cbc(aes)
driver       : hifn-aes
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>

name         : ecb(aes)
driver       : hifn-aes
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>

name         : ecb(des)
driver       : hifn-des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 8
max keysize  : 8
ivsize       : 0
geniv        : <default>

name         : cbc(des)
driver       : hifn-des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 8
max keysize  : 8
ivsize       : 0
geniv        : <default>

name         : ofb(des)
driver       : hifn-des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 8
max keysize  : 8
ivsize       : 0
geniv        : <default>

name         : cfb(des)
driver       : hifn-des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 8
max keysize  : 8
ivsize       : 0
geniv        : <default>

name         : ecb(des3_ede)
driver       : hifn-3des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 24
max keysize  : 24
ivsize       : 0
geniv        : <default>

name         : cbc(des3_ede)
driver       : hifn-3des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 24
max keysize  : 24
ivsize       : 0
geniv        : <default>

name         : ofb(des3_ede)
driver       : hifn-3des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 24
max keysize  : 24
ivsize       : 0
geniv        : <default>

name         : cfb(des3_ede)
driver       : hifn-3des
module       : hifn_795x
priority     : 300
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 8
min keysize  : 24
max keysize  : 24
ivsize       : 0
geniv        : <default>

name         : des3_ede
driver       : des3_ede-generic
module       : des_generic
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 24
max keysize  : 24

name         : des
driver       : des-generic
module       : des_generic
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 8
max keysize  : 8

name         : sha256
driver       : sha256-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 32

name         : sha224
driver       : sha224-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 28

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : cbc
priority     : 200
refcnt       : 2
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : aes
driver       : aes-asm
module       : aes_x86_64
priority     : 200
refcnt       : 3
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : md5
driver       : md5-generic
module       : kernel
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 16

It seems clear that some of the kernel CryptoAPI is now backed by the
hardware. It seems less clear on how to get userspace programs like Tor
to use the hardware.

Thoughts?

Best,
Jacob

[0] http://www.soekris.com/vpn1401.htm
[1] http://www.logix.cz/michal/devel/cryptodev/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100213/28ed11a9/attachment.pgp>


More information about the tor-dev mailing list