/dev/crypto not being used in 12-STABLE

[Jung-uk Kim]

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

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.

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

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

> 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.
> WITH_OPENSSL_ENGINE_DEVCRYPTO=true?

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 ]

Jung-uk Kim

1.
https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20181207/73f74f35/attachment.sig>