WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: padlock support for VIA processor  (Read 6394 times)

Offline FlyingDutchman

  • Newbie
  • *
  • Posts: 36
padlock support for VIA processor
« on: April 22, 2019, 04:49:54 AM »
Hello,

I'm running Corepure64 on a VIA processor. This processor supports hardware encryption (padlock). But I can't get it activated for OpenSSL.

output for dmesg:
Code: [Select]
dmesg | grep padlock
padlock_aes: Using VIA PadLock ACE for AES algorithm.
padlock_sha: Using VIA PadLock ACE for SHA1/SHA256 algorithms.

But Openssl can't find the engine:
Code: [Select]
openssl engine padlock
139920022353600:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:545:
139920022353600:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:390:id=padlock

Googling around I learned that two modules should be loaded for padlock support: padlock_aes and padlock_sha. But I can't find these in my installation. Is there any package that contains these modules?

Please advise.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
Re: padlock support for VIA processor
« Reply #1 on: April 22, 2019, 06:31:45 AM »

Offline FlyingDutchman

  • Newbie
  • *
  • Posts: 36
Re: padlock support for VIA processor
« Reply #2 on: April 23, 2019, 05:01:06 PM »
Hi Juanito,

I have read the bug description on GitHub and this does seem to be my issue. If I understand correctly, this is fixed in OpenSSL release 1.1.1? Any idea when that will be available in the repository?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
Re: padlock support for VIA processor
« Reply #3 on: April 25, 2019, 01:30:24 AM »
I've seen patch sets for openssl-0.9.8 and openssl-1.1.x, but not openssl-1.0.x - if you can find the patch set the changes can be made now.

The openssl update to 1.1.x would have to be a separate extension rather than a replacement of the current openssl(-1.0.x) as updating it would break many extensions.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
Re: padlock support for VIA processor
« Reply #4 on: April 28, 2019, 07:45:00 AM »
The bug is not yet fixed in openssl-1.1.1b...

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
Re: padlock support for VIA processor
« Reply #5 on: April 28, 2019, 10:00:11 AM »
I found the patches - openssl-1.1.0 posted.

I don't have the hardware to test, but padlock seems to work:
Code: [Select]
$ openssl engine padlock
(padlock) VIA PadLock (no-RNG, no-ACE)

Offline FlyingDutchman

  • Newbie
  • *
  • Posts: 36
Re: padlock support for VIA processor
« Reply #6 on: May 04, 2019, 11:20:09 AM »
Hi Juanito,

Thanks for the effort of providing a new package. I've installed openssl-1.1.0.tcz and indeed, this works. Hardware acceleration is enabled and I'm getting 10x more performance than before:
Code: [Select]
$ openssl speed -evp aes-256-cbc -engine padlock
engine "padlock" set.
Doing aes-256-cbc for 3s on 16 size blocks: 7149802 aes-256-cbc's in 2.76s
Doing aes-256-cbc for 3s on 64 size blocks: 6021218 aes-256-cbc's in 2.73s
Doing aes-256-cbc for 3s on 256 size blocks: 3122682 aes-256-cbc's in 2.77s
Doing aes-256-cbc for 3s on 1024 size blocks: 1048470 aes-256-cbc's in 2.69s
Doing aes-256-cbc for 3s on 8192 size blocks: 149526 aes-256-cbc's in 2.75s
Doing aes-256-cbc for 3s on 16384 size blocks: 73509 aes-256-cbc's in 2.71s
OpenSSL 1.1.1b  26 Feb 2019
built on: Sun Apr 28 17:28:25 2019 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe -fPIC -pthread -m64 -Wa,--noexecstack -Wall  -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DZLIB -DZLIB_SHARED -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc      41448.13k   141156.76k   288594.44k   399120.18k   445424.36k   444417.51k

Unfortunately, I can't get sshd, lighttpd and openvpn to work with the new openssl library:
  • When only installing openssl-1.1.0.tcz, they all complain about libssl.so.1.0.0 and libcrypto.so.1.0.0 missing.
  • If I add symbolic links for libssl.so.1.0.0 to libssl.so.1.1 and libcrypto.so.1.0.0 to libcrypto.so.1.1, all complain about missing symbols
  • If I first install openssl-1.1.0.tcz and then openssl.tcz, then the "openssl" command uses version 1.1.1b. OpenVPN, sshd and lighttpd work, but still use 1.0.2p

Any way to trick the applications in using the new openssl library? Or do they all need a re-compile? I need this for OpenVPN mainly, as the software encryption on my VPN gives me performance issues.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
Re: padlock support for VIA processor
« Reply #7 on: May 04, 2019, 12:54:31 PM »
You'll need to recompile openvpn against the new version of openssl  :(

Offline FlyingDutchman

  • Newbie
  • *
  • Posts: 36
Re: padlock support for VIA processor
« Reply #8 on: May 06, 2019, 01:13:49 PM »
Hi Juanito,

So, I recompiled openvpn against the new openssl version. I took some tries, but I think I managed. OpenVPN works, but I don't think it's using HW acceleration. I don't get better results on CPE usage or performance. Below some output from troubleshooting.

1) OpenVPN is compiled against OpenSSL 1.1.1b, as seen from the version output
Code: [Select]
$ openvpn --version
OpenVPN 2.4.3 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May  5 2019
library versions: OpenSSL 1.1.1b  26 Feb 2019, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_async_push='no' enable_comp_stub='no' enable_crypto='yes' enable_crypto_ofb_cfb='yes' enable_debug='yes'
enable_def_auth='yes' enable_dlopen='unknown' enable_dlopen_self='unknown' enable_dlopen_self_static='unknown' enable_fast_install='yes'
enable_fragment='yes' enable_iproute2='no' enable_libtool_lock='yes' enable_lz4='yes' enable_lzo='yes' enable_management='yes'
enable_multi='yes' enable_multihome='yes' enable_pam_dlopen='no' enable_pedantic='no' enable_pf='yes' enable_pkcs11='no'
enable_plugin_auth_pam='yes' enable_plugin_down_root='yes' enable_plugins='yes' enable_port_share='yes' enable_selinux='no'
enable_server='yes' enable_shared='yes' enable_shared_with_static_runtimes='no' enable_small='no' enable_static='yes' enable_strict='no'
enable_strict_options='no' enable_systemd='no' enable_werror='no' enable_win32_dll='yes' enable_x509_alt_username='no'
with_aix_soname='aix' with_crypto_library='openssl' with_gnu_ld='yes' with_mem_check='no' with_sysroot='no'

2) I checked what OpenVPN is linking to and the correct (new) versions of libssl and libcrypto seem to be used:
Code: [Select]
# ldd /usr/local/sbin/openvpn
linux-vdso.so.1 (0x00007ffe149e3000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00007f90b6393000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f90b637d000)
liblzo2.so.2 => /usr/local/lib/liblzo2.so.2 (0x00007f90b6162000)
libssl.so.1.1 => /usr/local/lib/libssl.so.1.1 (0x00007f90b60e8000)
libcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1 (0x00007f90b5e6e000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f90b5e69000)
libc.so.6 => /lib/libc.so.6 (0x00007f90b5ce9000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f90b5cd5000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f90b5cb7000)
/lib/ld-linux-x86-64.so.2 (0x00007f90b63b1000)

3) OpenSSL reports that the engine is available. I had to tweak openssl.cnf a bit to get this output. Although it reports that "Dynamic engine loading support" is unavailable. I have no idea if this is expected behavior.
Code: [Select]
# openssl engine -t -c
(dynamic) Dynamic engine loading support
     [ unavailable ]
(padlock) VIA PadLock (no-RNG, ACE)
 [AES-128-ECB, AES-128-CBC, AES-128-CFB, AES-128-OFB, AES-128-CTR, AES-192-ECB, AES-192-CBC, AES-192-CFB, AES-192-OFB, AES-192-CTR, AES-256-ECB, AES-256-CBC, AES-256-CFB, AES-256-OFB, AES-256-CTR]
     [ available ]

Code: [Select]
# openssl engine padlock -t -c
(padlock) VIA PadLock (no-RNG, ACE)
 [AES-128-ECB, AES-128-CBC, AES-128-CFB, AES-128-OFB, AES-128-CTR, AES-192-ECB, AES-192-CBC, AES-192-CFB, AES-192-OFB, AES-192-CTR, AES-256-ECB, AES-256-CBC, AES-256-CFB, AES-256-OFB, AES-256-CTR]
     [ available ]

4) But OpenVPN reports that hardware crypto engines are not available.
Code: [Select]
# openvpn --show-engines
Sorry, OpenSSL hardware crypto engine functionality is not available.

I looked up this error message in the source code. It is printed if a statement #if HAVE_OPENSSL_ENGINE in the file crypto_openssl.c returns "false". But I can't find what I have to do to get this to "true". Is that a compile time flag I have to set?

Please advise, and thanks for the time invested.

Offline FlyingDutchman

  • Newbie
  • *
  • Posts: 36
Re: padlock support for VIA processor
« Reply #9 on: May 06, 2019, 05:10:04 PM »
Final word: success!

I retried with the latest OpenVPN version (2.4.7) and compared the compile options with the options as set in the standard version from the repo (2.3.4). This meant adding "--enable-iproute2" and "--enable-ssl". Compiling was without error and indeed: now I get hardware support reported by OpenVPN:
Code: [Select]
# openvpn --show-engines
OpenSSL Crypto Engines

Dynamic engine loading support [dynamic]
VIA PadLock (no-RNG, ACE) [padlock]

I see a slight drop in CPU load, from 98% to 90%. Absolutely not the drop I hoped for initially, but I read in various threads that actually, CPU usage by OpenVPN is mainly spend on copying packets from kernel space to user space. Ah well, it's been an interesting ride anyway.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: padlock support for VIA processor
« Reply #10 on: May 07, 2019, 05:21:03 AM »
You may be interested in kernel-side solutions then. There's one popular one, WireGuard, which hasn't yet been merged but is available as patches. To use that one, you'd need to build your own kernel with the patches; I think there are other kernel-side VPN solutions too.
The only barriers that can stop you are the ones you create yourself.