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>
next in thread | previous in thread | raw e-mail | index | archive | help
As a party with a vested interest in FIPS, you can guess were I stand on re= placing OpenSSL with some other crypto engine in FreeBSD.=A0 ;)=0A= 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.=A0 This has been working quite well for us.=A0 We'= ll see what happens with our ongoing 12.2 upgrade.=0A= =0A= Not really the point of this email though. Regarding /dev/crypto:=0A= > Also, when I have tested it with actual offload hardware, it doesn't=0A= > really compete with native AES instructions on the CPU running in=0A= > userland.=0A= =0A= Here you're really comparing two hardware accelerators, one with extra kern= el overhead, so it's not really fair.=0A= Have you compared RSA or EC signing and verifying between libcrypto and /de= v/crypto?=A0 This would give you a better idea of /dev/crypto performance i= mprovement.=A0 (I'll say that /dev/crypto is not really of interest to me p= rofessionally, because FIPS)=0A= =0A= > KTLS does help because you can use sendfile, but=0A= > /dev/crypto is not a win in my testing.=A0 I had to make additional=0A= > changes to teach the engine in 1.0.2 to use AES-GCM with the=0A= > extensions needed for TLS as well as wire the user buffers to avoid=0A= > copies, and with that I got a hardware co-processor to break even=0A= > with AES-NI in userland in terms of both throughput and CPU usage=0A= > for HTTPS.=A0 sendfile-enabled KTLS, OTOH, is able to achieve=0A= > significantly higher throughput.=0A= =0A= I don't know anything about KTLS - is that using OpenSSL for it's crypto?= =A0 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 someth= ing we can disable... Is there some documentation about this someone can p= oint me to?=0A= =0A= - Steve Wall=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DM6PR09MB4807FB5F6315CAACCF25DBD7EEC70>