/dev/crypto not being used in 12-STABLE

Jeremy Chadwick jdc at koitsu.org
Sat Dec 8 00:31:52 UTC 2018

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/090202.html
> > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.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 Linux
> > called cryptodev-linux, then was made to work on FreeBSD 8.4.  This code
> > 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 doing
> > it all themselves?  Looking at the code sheds light on that.  The actual
> > 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

Because of this commit to OpenSSL's CHANGES file, which is part of what
I linked above; last sentence:


  *) 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]

Is this message incorrect/false?  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?

> 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.

Thanks for the information.

So this implies there is a desire to get rid of cryptodev(4) (which is
the /dev/crypto endpoint), at least on OpenBSD.

Apologies if this is off-topic, but: is "device cryptodev" something
that should be removed from one's kernel config (due to what sounds like
desired deprecation), while keeping "device crypto" (to ensure userland
applications that use libcrypto/crypto(4) functions can still get at

> > 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 interface:
> > 
> > https://github.com/openssl/openssl/pull/3744/files#diff-027f92eb0a10c0986aec873d9fd1ab66
> > 
> > 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 OpenSSL
> > 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.

Consider me surprised by this approach.  See below/end of my response.

> > 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.

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 any
light on the *priority* of engine selection in OpenSSL in scenarios
where devcrypto engine is enabled and aesni(4) is loaded/enabled.

> > 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 cards
> > 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.
> 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 ]

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:

$ 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 ]

You didn't answer my other two questions, so I'll repeat them:

If the intention is to keep the (new) devcrypto engine disabled, will
Release Notes reflect this fact, so that users/owners of H/W accelerator
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)

And what have you to say about my suggestion, re: src.conf tunable for
building/enabling the devcrypto engine?

| Jeremy Chadwick                                 jdc at koitsu.org |
| UNIX Systems Administrator                      PGP 0x2A389531 |
| Making life hard for others since 1977.                        |

More information about the freebsd-stable mailing list