On 18. 12. 7., Jeremy Chadwick wrote: > 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?
Yes, it is incorrect. > 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? There is config script but it does not change the configuration. >> 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. Yes. > 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))? I have no desire to deprecate cryptodev(4) from FreeBSD. I only disabled it for OpenSSL 1.1.1 because it was the default configuration. >>> 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. I just tried the devcrypto engine with aesni(4). Unfortunately, it didn't work for me. 3051 openssl NAMI "/dev/crypto" 3051 openssl RET openat 3 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument 3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0) 3051 openssl RET ioctl -1 errno 22 Invalid argument >>> 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 It works for me. % uname -or FreeBSD 11.2-RELEASE-p5 % openssl version OpenSSL 1.0.2o-freebsd 27 Mar 2018 % 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 (/usr/home/jkim/silly-engine.so) A silly engine for demonstration purposes Loaded: (silly) A silly engine for demonstration purposes [ available ] > 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) I am not re@ but re@ is well-aware of the situation, AFAIK. > And what have you to say about my suggestion, re: src.conf tunable for > building/enabling the devcrypto engine? I'll just enable devcrypto engine if it works and many users demand it. Jung-uk Kim
signature.asc
Description: OpenPGP digital signature
