Date: Thu, 6 Dec 2018 18:01:25 -0800 From: Jeremy Chadwick <jdc@koitsu.org> To: freebsd-stable@freebsd.org Subject: Re: /dev/crypto not being used in 12-STABLE Message-ID: <20181207020124.GA87799@icarus.home.lan>
next in thread | raw e-mail | index | archive | help
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@koitsu.org | | UNIX Systems Administrator PGP 0x2A389531 | | Making life hard for others since 1977. |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181207020124.GA87799>