I'm investigating issues with digest support and forks/threads. I haven't confirmed this, but it seems like there's a problem with processes that copy a message digest context from one process (or thread) to another one. sshd is the one I'm currently looking into. It seems to be creating two instances of the /dev/crypto engine, and then copying an MD context from one instance to the other one, causing an
ENOENT error, although I haven't seen those kernel error messages yet, but I haven't run openvpn. Try to apply https://patchwork.ozlabs.org/patch/1049156/ (the patch adds, among other goodies, the configuration options I'll use next) and then disable digests in
/etc/openssl.cnf: Add this line before any section (lines with brackets ):
Then, add the following sections anywhere past the last of the unsectioned commands (I add this to the very end of the file)--notice that you don't need the
CIPHERS line to enable all ciphers, I've added it here for reference:
Please tell me if the errors stop. Digests are not efficient anyways, at least not with the wrt3200acm (tested with
openssl speed, only with a block size of 16384, they are a bit faster than software). Perhaps with VPN traffic on jumbo frames they may be worth a try, but for most TLS applications, it is very slow. You can use different configuration files, btw, setting the
OPENSSL_CONF environment variable with the configuration filename.
I would disable the ECB ciphers as well, since they are used mostly in rng code, in small blocks (I don't recall if it is 16 or 64 bytes), where the cost of the ioctl (context switch) is high. I run mine with
CIPHERS=DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC
Note that, without the patch above, the engine is used for algorithms implemented in the kernel without hardware acceleration, which slows them down not matter what.
I will try to fix the copy issue, or else disable digests by default (probably best anyway).