Date: Fri, 7 Dec 2018 16:31:48 -0800 From: Jeremy Chadwick <jdc@koitsu.org> To: Jung-uk Kim <jkim@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: /dev/crypto not being used in 12-STABLE Message-ID: <20181208003148.GA9469@icarus.home.lan> In-Reply-To: <995cddb8-f4ce-b9c9-aa8f-5e7cd5c465e2@FreeBSD.org> References: <20181207020124.GA87799@icarus.home.lan> <995cddb8-f4ce-b9c9-aa8f-5e7cd5c465e2@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 07, 2018 at 06:38:04PM -0500, Jung-uk Kim wrote: > On 18. 12. 6., Jeremy Chadwick wrote: > > 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? > > Why do you think it is enabled by default? > > https://github.com/openssl/openssl/blob/619eb33/Configure#L428 Because of this commit to OpenSSL's CHANGES file, which is part of what I linked above; last sentence: https://github.com/openssl/openssl/pull/3744/files#diff-e4eb329834da3d36278b1b7d943b3bc9 *) Add devcrypto engine. This has been implemented against cryptodev-linux, then adjusted to work on FreeBSD 8.4 as well. Enable by configuring with 'enable-devcryptoeng'. This is done by default on BSD implementations, as cryptodev.h is assumed to exist on all of them. [Richard Levitte] Is this message incorrect/false? While I can read the perl code that is the Configure script just fine, the CHANGES entry makes me think there may be "other pieces" that affect the value of the key in that hash (e.g. some script that uses uname detection and calls Configure with argument). Are there? > Note crypto(4) was imported from OpenBSD. Since OpenBSD 4.9, it was > disabled by default. > > https://www.openbsd.org/plus49.html > > Then, they killed it in 5.7. > > https://www.openbsd.org/plus57.html > > o Unlinked the crypto(4) pseudo device (disabled by default for about 4 > years). > > Now FreeBSD is the only major BSD with /dev/crypto. That's why new > engine was not thoroughly tested. Thanks for the information. So this implies there is a desire to get rid of cryptodev(4) (which is the /dev/crypto endpoint), at least on OpenBSD. Apologies if this is off-topic, but: is "device cryptodev" something that should be removed from one's kernel config (due to what sounds like desired deprecation), while keeping "device crypto" (to ensure userland applications that use libcrypto/crypto(4) functions can still get at crypto(9))? > > 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? > > padlock has a dynamic engine, i.e., /usr/lib/engines/padlock.so. I > believe glxsb, hifn(4), safe(4), and ubsec(4) users are very rare > nowadays. If we have significant number of users and they show > reasonable performance, then I will reconsider my decision. Consider me surprised by this approach. See below/end of my response. > > 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)? > > I believe jhb@ answered this question already. Not really. "The fact that /dev/crypto trys to use it [aesni(4)] by default is a bug (IMO) that I'm planning on addressing" doesn't shed any light on the *priority* of engine selection in OpenSSL in scenarios where devcrypto engine is enabled and aesni(4) is loaded/enabled. > > 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? > > Actually, dynamic engines work as expected[1]. > > % openssl version > OpenSSL 1.1.1a-freebsd 20 Nov 2018 > % cat silly-engine.c > ... > % cc -fPIC -o silly-engine.o -c silly-engine.c > % cc -shared -o silly-engine.so -lcrypto silly-engine.o > % openssl engine -t -c `pwd`/silly-engine.so > (/home/jkim/silly-engine.so) A silly engine for demonstration purposes > Loaded: (silly) A silly engine for demonstration purposes > [ available ] Then this is another OpenSSL version change that should probably be documented in some manner in Release Notes, because dynamic engine has historically never been available on FreeBSD: $ openssl version OpenSSL 1.0.2p-freebsd 14 Aug 2018 $ openssl engine -t -v (cryptodev) BSD cryptodev engine [ available ] (dynamic) Dynamic engine loading support [ unavailable ] SO_PATH, NO_VCHECK, ID, LIST_ADD, DIR_LOAD, DIR_ADD, LOAD You didn't answer my other two questions, so I'll repeat them: If the intention is to keep the (new) devcrypto engine disabled, will Release Notes reflect this fact, so that users/owners of H/W accelerator cards/devices know that they'll be losing H/W acceleration offloading capability under OpenSSL? (While this doesn't impact me, I am thinking about other FreeBSD users who *do* have such hardware) And what have you to say about my suggestion, re: src.conf tunable for building/enabling the devcrypto engine? -- | 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?20181208003148.GA9469>