crypto accelaration

[JohnHughes]

I see some references on the web to "300Mbps" hardware crypo acceleration on the plug.

Is this true?  Is it accessible?  Documented?

Would it be possible to use this to speed up dm-crypt?  ssh?  openssl?

One tantalising hint from the boot messages is:

Code:

dm_crypt using the OCF package

[Rabeeh Khoury]

The Marvell official Linux kernel (LSP) supports OCF for offloading tasks to the security engine.
You can use openssl with the cryptodev extension to use the OCF offloading stack.

The mainline kernel.org still doesn't support the offload to the security engine, but i know people are working on this.

Withregards numbers, I don't know if it is 300Mbps or other.

[JohnHughes]

The Marvell official Linux kernel (LSP) supports OCF for offloading tasks to the security engine.

...

Withregards numbers, I don't know if it is 300Mbps or other.

Using the cryptotest from ocf I get:

# time ./cryptotest -a aes256 100000 4096
  21.285 sec,  200000 aes256 crypts,    4096 bytes, 38486888 byte/sec,   293.6 Mb/sec

real   0m21.291s
user   0m0.070s
sys   0m6.750s

Nearly 300Mb/sec using only 30% Cpu time.

Nice.

I'll try to get a patched OpenSSL so I can do some sw/hw comparisons.

[jmknapp]

According to the spec for the 88F6281 processor chip ("integrated controller"):

-----------------------------------------
Cryptographic engine

• Hardware implementation on encryption and
authentication engines, to boost packet processing
speed

• Dedicated DMA to feed the hardware engines with
data from the internal SRAM memory or from the
DDR memory

• Implements AES, DES, and 3DES encryption
algorithms

• Implements SHA1 and MD5 authentication
algorithms
--------------------------
http://archiv.rummelsdorf.org/files/83a96c38275bf07d826982f46df3210d/marvellkirkwood.PDF

[restamp]

A couple questions:

1. What is the resolution of this thread?  Is it correct to say that (1) there is an implementation of dm_crypt that utilizes the crypto engine on the 88F5182 architecture to speed up crypto tasks, (2) the Plug's 88F6281 architecture employs essentially the same hardware, and (3) mainline Linux has yet to port the Marvell dm_crypt mods to the kernel code for 88F6281?  If so, does anyone have any idea when this will be done?

2. Does the default OS that came with the Plug utilize its crypto engine?

3. What packages will support hardware-crypto when we finally get crypto acceleration integrated into the mainline code?  openssh?  openssl?  loopback devices?  Anything else?  I understand there will eventually be a /dev/crypto interface for user apps, right?

Inquiring minds want to know!  (Thanks!)

[Rabeeh Khoury]

1. There is an initial support. I'm not familiar with the status.
2. Yes. Marvell kernel 2.6.22.18 comes with crypto engine support using OCF stack
3. There are lots of stack that can accelerate with OCF; for example cryptodev in openssl, dmcrypt using OCF

[cobaia]

I have used VIAs inbuilt crypto engine on EPIA mobos with 100% success for about six months now on several active servers.

I can try if the same procedure works with Plug. I just need some time to sort out other unfinished business first.

[restamp]

FWIW, a friend just mailed me this:

BTW, in a post to the debian-arm list earlier today Martin mentioned he thinks that crypto engine support is supposed to be included in the 2.6.32 kernel for the Orion and Kirkwood families of SoC devices.  If true, it would be a nice Christmas present.

So, maybe us crypto-types won't have to wait much longer to take advantage of the Plug's native crypto-support!

[theblop]

FWIW, a friend just mailed me this:

BTW, in a post to the debian-arm list earlier today Martin mentioned he thinks that crypto engine support is supposed to be included in the 2.6.32 kernel for the Orion and Kirkwood families of SoC devices.  If true, it would be a nice Christmas present.

So, maybe us crypto-types won't have to wait much longer to take advantage of the Plug's native crypto-support!

Is it possible to patch the 2.6.31 kernel with the crypt engine support that Marvell uses in 2.6.22?
It would be nice not to have to wait until Christmas

I get only about 5 MB/s read/write with dm_crypto on a 200GB HD connected to the plug via USB (see below).

I got 30 MB/s on the same disk without encryption!

Code:

# WRITING
dd if=/dev/zero of=/mnt/test bs=1000k count=500
512000000 bytes (512 MB) copied, 103.472 s, 4.9 MB/s

# READING
dd if=/mnt/test of=/dev/null
512000000 bytes (512 MB) copied, 90.4974 s, 5.7 MB/s

[restamp]

How do you successfully set up an encrypted disk on one of the modern kernels, theblop?  Every time I try to use cryptsetup I get a NULL pointer dereference error.  Right now, I'd be delighted to get 5MB/sec to an encrypted FS.

(FWIW, I notice that most Ubuntus have a loadable aes module, but this seems lacking on the kernels provided here.)

[theblop]

How do you successfully set up an encrypted disk on one of the modern kernels, theblop?  Every time I try to use cryptsetup I get a NULL pointer dereference error.  Right now, I'd be delighted to get 5MB/sec to an encrypted FS.

(FWIW, I notice that most Ubuntus have a loadable aes module, but this seems lacking on the kernels provided here.)

I'm still using 2.6.29-2-kirkwood as found in http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html

From what I've read in this forum, no one got dm_crypt to work on the 2.6.3x kernels so I'm holding off the upgrade.

I also tried to compile truecrypt as an alternative but that didn't work either: http://plugcomputer.org/plugforum/index.php?topic=737.0

[theblop]

How do you successfully set up an encrypted disk on one of the modern kernels, theblop?  Every time I try to use cryptsetup I get a NULL pointer dereference error.  Right now, I'd be delighted to get 5MB/sec to an encrypted FS.

(FWIW, I notice that most Ubuntus have a loadable aes module, but this seems lacking on the kernels provided here.)

Update:

I compiled the latest orion kernel (http://git.marvell.com/?p=orion.git;a=summary) which has all the Marvell patches, including hardware crypto (as long as you specify CRYPTO_DEV_MV_CESA=y or m in the kernel config) and I get about 10MB/s read/write on a usb2 hard disk, which is about 3 times slower than unencrypted but still better than the 5MB/s I got without hardware support.

The CESA module will also be in mainline 2.6.32.

[bert64]

I have a 2.6.32 kernel with the mv_cesa module loaded, and shows up in /proc/crypto:

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

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

I also have the OCF patches applied, so /dev/crypto shows up as it should... OCF is compiled in to the kernel because it wouldn't compile successfully as a module..

I have a version of OpenSSL patched to support the cryptodev engine, but the performance seems unaffected.. I would assume the OCF driver is not working correctly and OpenSSL is falling back to its standard crypt routines.

[fun]

hello

CESA driver in 2.6.32 is implemented for Async Crypto API, but OCF-Linux (and CryptoDev for Linux) doesn't support Async Crypto API.

 http://sourceforge.net/mailarchive/forum.php?thread_name=20091213233047.GA20578%40mcafee.com&forum_name=ocf-linux-users
 http://plugcomputer.org/plugforum/index.php?topic=1014.0

it seems CESA driver in LSP kernel (2.6.22.18) is implemented as OCF driver. If you want to use CESA via openssl cryptodev engine, you should use LSP kernel until OCF-Linux supports Async Crpyto API.

[mgillespie]

The only words I understood of that last post where "hello"...