Activating AES hardware on ARM board?


I just bought another MyBook Live 3TB to get another go at the encryption of /DataVolume.

So far, I have upgraded to 02.01.06, and recompiled the dm-crypt and loop modules successfully for the -svn22440 kernel succesfully so I can use LUKS and EncFS.

Some benchmarks:

Copying a 600 MB file over 100MBit/s network to …

   … the Public share:  11MB/s (this would be much faster with a GBit network)

   … an EncFS mount on the Public share: 3,5 MB/s (see below)

   … an encrypted 1GB image file on the Public share: 8 MB/s (around 11MB/s when copying locally from /dev/zero)

So, encryption significaly lowers performance. But the device has a hardware based encryption support (see “crypto4xx” driver below), which is actually active by default but apparently not used. EncFS and dm-crypt would probably significantly benefit from this support.


How do I activate the crypto4xx driver (which is compiled into the default kernel and actually finds the AES hardware, see below) so that dm-crypt and openssl can use it? What encryption throughput can I expect from the hardware on board the device?

( Note to WD support:

I am not intending to return the device, and I have made an image of the firmware and am able to restore it if something breaks, so pretty please tell me. :slight_smile: )

Thank you!

Here are some more specs.

Linux Kernel 2.6.32-11 , Debian Lenny with some packages from Debian Squeeze

# cat /proc/cpuinfo 

processor: 0

cpu: APM82181

clock: 800.000008MHz

revision: 28.130 (pvr 12c4 1c82)

bogomips: 1600.00

timebase: 800000008

platform: PowerPC 44x Platform

model: amcc,apollo3g

Memory: 256 MB

# cat /proc/modules 

fuse 57929 1 - Live 0xd19a0000

dm_crypt 12663 0 - Live 0xd1800000

dm_mod 60644 1 dm_crypt, Live 0xd1550000

dmesg extract:

# dmesg|grep -i crypt

Cryptodev Interface Loaded

User space CryptoAPI driver v0.1 loaded

this is actually outdated - CryptoAPI v1.0 is released.

# cat /proc/crypto|grep name

name         : tls1_1(NULL-sha1)

name         : tls1_1(NULL-md5)

name         : tls1_1(arc4-md5)

name         : tls1_1(arc4-sha1)

name         : tls1_1(des3-sha1)

name         : tls1_1(des-sha1)

name         : tls1_1(aes-sha1)

name         : tls(NULL-sha1)

name         : tls(NULL-md5)

name         : tls(arc4-md5)

name         : tls(arc4-sha1)

name         : tls(des3-sha1)

name         : tls(des-sha1)

name         : tls(aes-sha1)

name         : ssl(NULL-sha1)

name         : ssl(NULL-md5)

name         : ssl(arc4-md5)

name         : ssl(arc4-sha1)

name         : ssl(des3-sha1)

name         : ssl(des-sha1)

name         : ssl(aes-sha1)

name         : f9(kasumi)

name         : f8(kasumi)

name         : kasumi

name         : hmac(sha1)

name         : md5

name         : ghash

name         : stdrng

name         : deflate

name         : arc4

name         : aes

name         : des3_ede

name         : des

name         : sha512

name         : sha384

name         : sha256

name         : sha224

name         : sha1

name         : md5

# cat /proc/driver/crypto4xx/crypto4xx

ring_ctrl_val = 0x00010008

Crypto4xx Controller on AMCC PPC 460EX Canyonlands Board

31 packets received for packetsize = 85                  

31 interrupts received

So, the crypto functions are active in the kernel.  But the “packets received” number does not increase when I use encrypted (loop) partitions. So I suppose they are not used. If they are, how do I see the difference?

stefan29, Western Digital will not provide information that could compromise, damage, alter or degrade a product, with or without your consent; specially when said information could prevent you from having access to any retail purchase benefit, such as the right for a Warranty Claim / RMA.