Encryption, performance and hardware acceleration

[Olivier Croquette]

Hi,

I am experimenting with the encryption. I have created successfully an encrypted partition with the web interface. Here is what cryptsetup reports about it:

[root@dns323]# cryptsetup status /dev/dm-0
/dev/dm-0 is active and is in use.
  type:    LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 128 bits
  device:  /dev/sda3
  offset:  2048 sectors
  size:    1246674082 sectors
  mode:    read/write

Here is the kind of performance I get:

[root@dns323]# dd if=/dev/zero of=/mnt/sda3-crypt/tmp count=100 bs=1000000
100+0 records in
100+0 records out
100000000 bytes (95.4MB) copied, 43.143049 seconds, 2.2MB/s

Compared to a non-encrypted partition:

[root@dns323]# dd if=/dev/zero of=/mnt/sda2/tmp count=100 bs=1000000
100+0 records in
100+0 records out
100000000 bytes (95.4MB) copied, 3.457027 seconds, 27.6MB/s

2.2 MB/s is barely useable. I tried to activate the hardware acceleration in the web UI, but it doesn't seem to make any difference.
How can I make sure that the partition uses the HW acceleration ?
Looking at the content of /proc/crypto, I have the feeling that no HW acceleration is even supported on my system, even though mv_cesa is loaded.

Thanks for your help,
Olivier

[root@dns323]# lsmod
Module                  Size  Used by    Tainted: G  
cryptodev              29636  0
mv_cesa                 8912  0
cbc                     1772  1
dm_crypt               12288  1
dm_mod                 51532  3 dm_crypt
usblp                   7876  0

[root@dns323]# cat /proc/crypto
name         : cbc(aes)
driver       : cbc(aes-generic)
module       : kernel
priority     : 100
refcnt       : 2
selftest     : passed
type         : givcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : chainiv

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

name         : stdrng
driver       : ansi_cprng
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
type         : rng
seedsize     : 48

name         : stdrng
driver       : krng
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
type         : rng
seedsize     : 0

name         : crc32c
driver       : crc32c-generic
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 1
digestsize   : 4

name         : ecb(arc4)
driver       : ecb(arc4)-generic
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
type         : blkcipher
blocksize    : 1
min keysize  : 1
max keysize  : 256
ivsize       : 0
geniv        : <default>

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

name         : aes
driver       : aes-generic
module       : kernel
priority     : 100
refcnt       : 4
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

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

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

name         : sha224
driver       : sha224-generic
module       : kernel
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 28

name         : sha256
driver       : sha256-generic
module       : kernel
priority     : 0
refcnt       : 3
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 32

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

name         : md4
driver       : md4-generic
module       : kernel
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 16

[João Cardoso]

The initscript, 'rccryptsetup start|stop|status|load|unload' should load all needed modules and start all needed services. It should be automatically be launched at boot when a crypto partitions in detected; the webUI might fail or be resilient. There are several services involved (device mapper, module loading...)

In you case mv_cesa is not in use, so you have no hw acceleration at use. if I remember correctly it will double your current read/write speed. It was tested on the dns-323.

[João Cardoso]

My results on a DNS-320L, which is (twice? thrice?)  faster than a DNS-323, on a 1GB partition:

[root@dns-320l]# lsmod 

Module                  Size  Used by    Not tainted

mv_cesa                 8912  1 

dm_crypt               12288  1 

dm_mod                 51532  2 dm_crypt

usblp                   8292  0 

[root@dns-320l]# dd if=/dev/zero of=/mnt/sdb4-crypt/tmp count=100 bs=1000000

100+0 records in

100+0 records out

100000000 bytes (95.4MB) copied, 7.754769 seconds, 12.3MB/s

But as the DNS-320L system memory is 256MB, do not use files smaller then that, or memory caching will occur biasing the results. Repeating:

[root@dns-320l]# dd if=/dev/zero of=/mnt/sdb4-crypt/tmp count=1000 bs=1000000

1000+0 records in

1000+0 records out

1000000000 bytes (953.7MB) copied, 96.203392 seconds, 9.9MB/s

And/or to guarantee real timing, wait for the disk operations to finish using dd's fsync:

[root@dns-320l]# dd if=/dev/zero of=/mnt/sdb4-crypt/tmp count=100 bs=1000000 conv=fsync

100+0 records in

100+0 records out

100000000 bytes (95.4MB) copied, 15.457470 seconds, 6.2MB/s

The webUI is faulty, you have to enter the passwd file and check the hw accelerator checkbox and Submit, before formating or opening the device.

[Olivier Croquette]

On Wednesday, June 10, 2015 at 8:55:11 PM UTC+2, João Cardoso wrote:

My results on a DNS-320L, which is (twice? thrice?)  faster than a DNS-323, on a 1GB partition:

[root@dns-320l]# lsmod 

Module                  Size  Used by    Not tainted

mv_cesa                 8912  1 

dm_crypt               12288  1 

dm_mod                 51532  2 dm_crypt

usblp                   8292  0 

Thanks for your reply. The WebUI looks really buggy :) But for one reason, I cannot get mv_cesa to be used, even manually:

[root@dns323]# lsmod
Module                  Size  Used by    Tainted: G 

dm_crypt               12288  0
dm_mod                 51532  1 dm_crypt
mv_cesa                 8912  0
cryptodev              29636  0
cbc                     1772  0
usblp                   7876  0
[root@dns323]# cryptsetup --key-file=/mnt/CORSAIR16/keyfile luksOpen /dev/sda3 sda3-crypt

[root@dns323]# lsmod
Module                  Size  Used by    Tainted: G 

dm_crypt               12288  1
dm_mod                 51532  2 dm_crypt

mv_cesa                 8912  0
cryptodev              29636  0
cbc                     1772  1
usblp                   7876  0

[root@dns323]# cryptsetup status /dev/dm-0

/dev/dm-0 is active.

[Olivier Croquette]

Hi,

I gave it a try again tonight, still no luck. mv_cesa is always shown as unused, and there is no trace of it in /proc/crypto. There are no messages in dmesg either.
Is there anything I could try out ?
Has anyone the HW supported encryption working on the DNS-323 ?

Olivier

[D D]

Hello!

Sorry to append to this years old thread but the keyword of hardware acceleration got my attention.

As you might know from my previous thread I set up an OpenVPN connection from my DNS-323 to a remote server.

But it seems this connection does not exceed a performance of 9Mbit/s (<1MB/s) on my DSL100 line (server side) / DSL50 line (client side).

At least downloading to the DNS-323 should run with up to 40Mbit/s (8MB/s) reduced by VPN overhead of course.

I already tried openVPN with "-comp-lzo no" but this gave even worse results than with the standard setting "-comp-lzo" (~4-5Mbit/s).

I there any way to use hardware acceleration to increase my throughput?

In the CPU specs I could read that a HW acceleration engine is included:

https://www.insidegadgets.com/wp-content/uploads/2014/06/88F5182.pdf

Many thanks for any hint.

[João Cardoso]

On Friday, 8 May 2020 19:36:48 UTC+1, D D wrote:

Hello!

Sorry to append to this years old thread but the keyword of hardware acceleration got my attention.

As you might know from my previous thread I set up an OpenVPN connection from my DNS-323 to a remote server.

But it seems this connection does not exceed a performance of 9Mbit/s (<1MB/s) on my DSL100 line (server side) / DSL50 line (client side).

At least downloading to the DNS-323 should run with up to 40Mbit/s (8MB/s) reduced by VPN overhead of course.

I already tried openVPN with "-comp-lzo no" but this gave even worse results than with the standard setting "-comp-lzo" (~4-5Mbit/s).

I there any way to use hardware acceleration to increase my throughput?

I don't think so.

This thread is about disk encryption using cryptsetup, which uses (LVM) device-mapper, which uses the kernel hardware crypto system. It works fine (but not on the DNS-323/321, I think to remember. Yes, the 1.0 release notes say -Hardware accelerated crypto device: mv-cesa driver replaced by newer marvell-cesa. 

 Not working on the DNS-321/323.)

What you want is to make openssl (used by  openvpn), to use the kernel hardware crypto system, and that is not working. If you search the web for "openssl marvell cesa" you will find a lot of steps forward and setbacks, from different distros. The "Hardware Accelerator" checkbox tooltip in Alt-F even says that "some openssl operations might stop working", or similar.

I tried valiantly, but without success. 'cryptodev' is not used, or wrongly used, by openssl, and openssl does not seems interested in correcting that.

So that is a lost battle.