FreeBSD Security Advisory FreeBSD-SA-20:33.openssl

[Wall, Stephen]

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 Wall