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/
signature.asc
Description: OpenPGP digital signature
