From owner-freebsd-stable@freebsd.org Sat Dec 8 03:55:25 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F5CC132F09B for ; Sat, 8 Dec 2018 03:55:25 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F234A6B584; Sat, 8 Dec 2018 03:55:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (static-71-168-218-4.cmdnnj.fios.verizon.net [71.168.218.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C4D731A5DE; Sat, 8 Dec 2018 03:55:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: /dev/crypto not being used in 12-STABLE To: Jeremy Chadwick Cc: freebsd-stable@freebsd.org References: <20181207020124.GA87799@icarus.home.lan> <995cddb8-f4ce-b9c9-aa8f-5e7cd5c465e2@FreeBSD.org> <20181208003148.GA9469@icarus.home.lan> From: Jung-uk Kim Openpgp: preference=signencrypt Autocrypt: addr=jkim@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJBztUBCAChqNyGqmFuNo0U7MBzsD+q/G6Cv0l7LGVrOAsgh34M8wIWhD+tztDWMVfn AhxNDd0ceCj2bYOe67sTQxAScEcbt2FfvPOLp9MEXb9qohZj172Gwkk7dnhOhZZKhVGVZKM4 NcsuBDUzgf4f3Vdzj4wg6WlqplnTZo8lPE4hZWvZHoFIyunPTJWenybeV1xnxK7JkUdSvQR0 fA59RfTTECMwTrSEfYGUnxIDBraxJ7Ecs/0hGQ7sljIj8WBvlRDU5fU1xfF35aw56T8POQRq F4E6RVJW3YGuTpSwgtGZOTfygcLRhAiq3dFC3JNLaTVTpM8PjOinJyt9AU6RoITGOKwDABEB AAHNHkp1bmctdWsgS2ltIDxqa2ltQEZyZWVCU0Qub3JnPsLAfQQTAQoAJwUCUkHO1QIbAwUJ E0/POwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRB8n5Ym/NvxRqyzB/wL7QtsIpeGfGIA ZPMtgXMucM3NWzomyQMln2j2efUkDKthzh9jBxgF53TjOr7imwIt0PT2k1bqctPrq5IRqnu9 mGroqaCLE3LG2/E3jEaao4k9PO6efwlioyivUo5NrqIQOQ4k3EAXw7d2y0Dk1VpTgdMrnUAB hj7lGlLqS4ydcrf24DdbCRGdEQwqd9DBeBgbWynxAJMgbZBhYVEyIHuQKkJ8qY0ibIPXXuF0 KYDeH0qUHtWV2K3srNyPtymUkBQD84Pl1GWRYx05XdUHDmnX0JV3lg0BfYJZgZv0ehPQrMfY Fd9abTkf9FHQYz1JtsC8wUuRgqElRd6+YAGf8Tt9zsBNBFJBztUBCADLtSrP44El2VoJmH14 OFrlOgxzZnbn+Y/Gf1k12mJBiR+A+pBeRLD50p7AiTrjHRxO3cHcl9Dh0uf1VSbXgp8Or0ye iP/86fZPd4k5HXNmDTLL0HecPE08SCqGZ0W8vllQrokB1QxxRUB+fFMPJyMCjDAZ7P9fFTOS dTw1bJSTtOD8Sx8MpZUa9ti06bXFlVYDlaqSdgk181SSx+ZbSKkQR8CIMARlHwiLsa3Z9q9O EJr20HPyxe0AlTvwvFndH61hg7ds63eRvglwRnNON28VXO/lvKXq7Br/CiiyhFdKfINIx2Z5 htYq22tgGTW7mBURbIKoECFBTX9Lv6BXz6w9ABEBAAHCwGUEGAEKAA8FAlJBztUCGwwFCRNP zzsACgkQfJ+WJvzb8UZcJQf+IsTCxUEqY7W/pT84sMg5/QD3s6ufTRncvq14fEOxCNq1Rf4Q 9P+tOFa8GZfKDGB2BFGIrW7uT5mlmKdK1vO6ZIA930y5kUsnCmBUEBJkE2ciSQk01aB/1o62 Q3Gk/F6BwtNY9OXiqF7AcAo+K/BMIaqb26QKeh+IIgK1NN9dQiq3ByTbl4zpGZa6MmsnnRTu mzGKt2nkz7vBzH6+hZp1OzGZikgjjhYWVFoJo1dvf/rv4obs0ZJEqFPQs/1Qa1dbkKBv6odB XJpPH0ssOluTY24d1XxTiKTwmWvHeQkOKRAIfD7VTtF4TesoZYkf7hsh3e3VwXhptSLFnEOi WwYofg== Message-ID: <8c7be0a2-65a7-2313-4c18-fab8ca89884a@FreeBSD.org> Date: Fri, 7 Dec 2018 22:55:18 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <20181208003148.GA9469@icarus.home.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EyhfopjnksLycK5eay2ezddf9VqscPVRk" X-Rspamd-Queue-Id: F234A6B584 X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 03:55:25 -0000 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 To: Jeremy Chadwick 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--