Date: Fri, 7 Dec 2018 22:55:18 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-stable@freebsd.org Subject: Re: /dev/crypto not being used in 12-STABLE Message-ID: <8c7be0a2-65a7-2313-4c18-fab8ca89884a@FreeBSD.org> In-Reply-To: <20181208003148.GA9469@icarus.home.lan> References: <20181207020124.GA87799@icarus.home.lan> <995cddb8-f4ce-b9c9-aa8f-5e7cd5c465e2@FreeBSD.org> <20181208003148.GA9469@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EyhfopjnksLycK5eay2ezddf9VqscPVRk Content-Type: multipart/mixed; boundary="wwCO4Z17htNhPX90RZQSbc1z16fzeyJJs"; protected-headers="v1" From: Jung-uk Kim <jkim@FreeBSD.org> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-stable@freebsd.org Message-ID: <8c7be0a2-65a7-2313-4c18-fab8ca89884a@FreeBSD.org> Subject: Re: /dev/crypto not being used in 12-STABLE References: <20181207020124.GA87799@icarus.home.lan> <995cddb8-f4ce-b9c9-aa8f-5e7cd5c465e2@FreeBSD.org> <20181208003148.GA9469@icarus.home.lan> In-Reply-To: <20181208003148.GA9469@icarus.home.lan> --wwCO4Z17htNhPX90RZQSbc1z16fzeyJJs Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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/0902= 02.html >>> https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/0902= 02.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 Linu= x >>> called cryptodev-linux, then was made to work on FreeBSD 8.4. This c= ode >>> 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 doin= g >>> it all themselves? Looking at the code sheds light on that. The act= ual >>> 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 >=20 > Because of this commit to OpenSSL's CHANGES file, which is part of what= > I linked above; last sentence: >=20 > https://github.com/openssl/openssl/pull/3744/files#diff-e4eb329834da3d3= 6278b1b7d943b3bc9 >=20 > *) 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] >=20 > 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. >=20 > Thanks for the information. >=20 > 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 lik= e > 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 interfac= e: >>> >>> https://github.com/openssl/openssl/pull/3744/files#diff-027f92eb0a10c= 0986aec873d9fd1ab66 >>> >>> 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 OpenSS= L >>> 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. >=20 > Consider me surprised by this approach. See below/end of my response. >=20 >>> 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. >=20 > 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 an= y > 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 card= s >>> 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=3Dtrue? >> >> 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 ] >=20 > 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: >=20 > $ 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 purpose= s Loaded: (silly) A silly engine for demonstration purposes [ available ] > You didn't answer my other two questions, so I'll repeat them: >=20 > If the intention is to keep the (new) devcrypto engine disabled, will > Release Notes reflect this fact, so that users/owners of H/W accelerato= r > 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 --wwCO4Z17htNhPX90RZQSbc1z16fzeyJJs-- --EyhfopjnksLycK5eay2ezddf9VqscPVRk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlwLQKcACgkQfJ+WJvzb 8UZvMAf+N4kmRspFm7iRKxhddnhZVfgwqNcKX3Z+NIDCFnFiRv6B7jBV1VvZu+HE c58r6ML5witF9GHVILBNjsFJRI/IUyQoh0W0oefDZ/Z6u+WDxk6RCVQHvrd797jB oSG7CfOj65iyce7Oj0g9g2IkFXq4dOyRdN3oUQ/6r0GR27AYrj2C+6X53SS+9sdE MrOglMqfIegzZlbcM8ZQNtSnOqUtEhpEvsAI/5ChVXQZmbZxotzxPoOCH39lZtsv fKpswwzSfCoK672DOr7JEaBFoeu1YlLpMdxtJ4G4UjGux36DYkaEa/rrqymOOxF0 h9mzz7DmaHpxNQPEFVh+CT1EsurwmA== =u0jN -----END PGP SIGNATURE----- --EyhfopjnksLycK5eay2ezddf9VqscPVRk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8c7be0a2-65a7-2313-4c18-fab8ca89884a>