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:
https://github.com/openssl/openssl/pull/3744/files#diff-e4eb329834da3d36278b1b7d943b3bc9
*) 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
crypto(9))?
> > 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.
> > 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 ]
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 ]
SO_PATH, NO_VCHECK, ID, LIST_ADD, DIR_LOAD, DIR_ADD, LOAD
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. |