/dev/crypto not being used in 12-STABLE

[Jeremy Chadwick]

I'm not subscribed to -stable.

This is in response to jkim@'s messages here:

https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html
https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html

Based on what I can tell, OpenSSL 1.1.1 or thereabouts removed the
cryptodev OpenSSL engine, which was a tie-in to BSD's cryptodev(4),
which is accessed via /dev/crypto and related crypto(4) ioctls.

Instead, they offered a replacement engine called devcrypto (what an
awful name), with the primary focus being against something from Linux
called cryptodev-linux, then was made to work on FreeBSD 8.4.  This code
was as of June 2017; 8.4 was EOL'd August 2015.  Interesting.

https://github.com/openssl/openssl/commit/4f79aff is not "add support
for BSD" at all.  It's "tweak further stuff for BSD", probably to get it
to work on newer FreeBSD; they seem to care about crypto/cryptodev.h
details.  I asked myself: why do they care about that if they're doing
it all themselves?  Looking at the code sheds light on that.  The actual
devcrypto engine commits that added BSD support are here:

https://github.com/openssl/openssl/pull/3744
https://github.com/openssl/openssl/pull/3744/files

The commits indicate that the devcrypto is enabled by default on
FreeBSD.  But we can tell from Herbert's post and jkim@'s patch that's
not true at all, i.e. FreeBSD disables it.  Why?  And is that a good
default?  Here's why I ask:

The new devcrypto engine most definitely utilises /dev/crypto (thus
cryptodev(4) and crypto(4)).  cipher_init(), prepare_cipher_methods(),
digest_init(), and prepare_digest_methods() all utilise that interface:

https://github.com/openssl/openssl/pull/3744/files#diff-027f92eb0a10c0986aec873d9fd1ab66

So while OpenSSL now uses more of its own native C and assembly code
(e.g. for AES-NI support), and that's certainly faster than all the
overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder:

1. What happens to people using crypto hardware accelerators, ex.
hifn(4), padlock(4), ubsec(4), and safe(4)?  How exactly would OpenSSL
utilise these H/W accelerators if the devcrypto engine is disabled?

2. If the devcrypto engine is *enabled*, and people have aesni(4)
loaded alongside cryptodev(4), which gets priority: OpenSSL's native
AES-NI code or cryptodev(4)/aesni(4)?

Likewise: if the decrypto engine is to remain disabled as a default:
this needs to be made crystal clear in Release Notes, so that folks
using H/W accelerators know they'll no longer benefit from those cards
unless they use a patch (third-party so/module won't work, AFAIT, as
OpenSSL's dynamic engine loading is unavailable per openssl engine -t).
Might I suggest enabling devcrypto be capable via src.conf, ex.
WITH_OPENSSL_ENGINE_DEVCRYPTO=true?

-- 
| Jeremy Chadwick                                 jdc at koitsu.org |
| UNIX Systems Administrator                      PGP 0x2A389531 |
| Making life hard for others since 1977.                        |