Date: Mon, 14 Dec 2020 20:53:16 +0000 From: "Wall, Stephen" <stephen.wall@redcom.com> To: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl Message-ID: <DM6PR09MB4807FB5F6315CAACCF25DBD7EEC70@DM6PR09MB4807.namprd09.prod.outlook.com> In-Reply-To: <63bb8800-e756-9b9b-0ec3-8f91097b6738@FreeBSD.org> References: <20201209230300.03251CA1@freefall.freebsd.org> <20201211064628.GM31099@funkthat.com> <813a04a4-e07a-9608-40a5-cc8e339351eb@FreeBSD.org> <20201213005708.GU31099@funkthat.com>, <63bb8800-e756-9b9b-0ec3-8f91097b6738@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
As a party with a vested interest in FIPS, you can guess were I stand on replacing OpenSSL with some other crypto engine in FreeBSD. ;) We are currently building FreeBSD 11.4 against a copy of the latest OpenSSL 1.0.2 release by diverting the build to a separate part of our source tree in secure/lib/Makefile. This has been working quite well for us. We'll see what happens with our ongoing 12.2 upgrade. Not really the point of this email though. Regarding /dev/crypto: > Also, when I have tested it with actual offload hardware, it doesn't > really compete with native AES instructions on the CPU running in > userland. Here you're really comparing two hardware accelerators, one with extra kernel overhead, so it's not really fair. Have you compared RSA or EC signing and verifying between libcrypto and /dev/crypto? This would give you a better idea of /dev/crypto performance improvement. (I'll say that /dev/crypto is not really of interest to me professionally, because FIPS) > KTLS does help because you can use sendfile, but > /dev/crypto is not a win in my testing. I had to make additional > changes to teach the engine in 1.0.2 to use AES-GCM with the > extensions needed for TLS as well as wire the user buffers to avoid > copies, and with that I got a hardware co-processor to break even > with AES-NI in userland in terms of both throughput and CPU usage > for HTTPS. sendfile-enabled KTLS, OTOH, is able to achieve > significantly higher throughput. I don't know anything about KTLS - is that using OpenSSL for it's crypto? If so, can it load a FIPS canister/provider? If not, then FIPS may be an issue for us (and other commercial users of FreeBSD), I hope it's something we can disable... Is there some documentation about this someone can point me to? - Steve Wallhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DM6PR09MB4807FB5F6315CAACCF25DBD7EEC70>