On 18. 12. 7., Jeremy Chadwick wrote:> 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?
Yes, it is incorrect.
> 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?
There is config script but it does not change the configuration.
>> 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.
Yes.
> 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))?
I have no desire to deprecate cryptodev(4) from FreeBSD. I only
disabled it for OpenSSL 1.1.1 because it was the default configuration.
>>> 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.
I just tried the devcrypto engine with aesni(4). Unfortunately, it
didn't work for me.
3051 openssl NAMI "/dev/crypto"
3051 openssl RET openat 3
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
3051 openssl CALL ioctl(0x3,CIOCGSESSION,0x7fffffffe3e0)
3051 openssl RET ioctl -1 errno 22 Invalid argument
>>> 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
It works for me.
% uname -or
FreeBSD 11.2-RELEASE-p5
% openssl version
OpenSSL 1.0.2o-freebsd 27 Mar 2018
% 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
(/usr/home/jkim/silly-engine.so) A silly engine for demonstration purposes
Loaded: (silly) A silly engine for demonstration purposes
[ available ]
> 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)
I am not re@ but re@ is well-aware of the situation, AFAIK.
> And what have you to say about my suggestion, re: src.conf tunable for
> building/enabling the devcrypto engine?
I'll just enable devcrypto engine if it works and many users demand it.
Jung-uk Kim
-------------- 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/ef60cc45/attachment.sig>