freebsd stable - Dec 2018 - /dev/crypto not being used in 12-STABLE

On 12/6/18 3:24 PM, John Nielsen wrote:
>> On Dec 6, 2018, at 4:04 PM, Xin LI <delphij at gmail.com> wrote:
>>
>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen <lists at
jnielsen.net> wrote:
>>>
>>> I have upgraded two physical machines from 11-STABLE to 12-STABLE
recently (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE
r341391). I noticed today that neither machine seems to be utilizing
/dev/crypto. Typically I see at least ssh/sshd have the device open plus some
programs from ports. But 'fuser' doesn't list any processes on
either machine:
>>>
>>> # fuser /dev/crypto
>>> /dev/crypto:
>>>
>>> Both machines are running custom kernels that include "device
crypto" and "device cryptodev". One of them additionally has
"device aesni".
>>>
>>> Is anyone else seeing this? Any idea what would cause it?
>>
>> Your average OpenSSL applications should not use /dev/crypto, if your
>> goal is to utilize AES-NI (which does not require /dev/crypto).  On
>> capable systems, AES-NI would be used automatically (and it's
faster
>> this way).
> 
> Thanks for the response. Is there a way to verify that AES-NI is being used
for e.g. ssh? I'm also curious why/when/how the change to not use (or
support?) /dev/crypto from base openssl was made.
I suspect it was something we just didn't test in the flurry of other work
during the OpenSSL upgrade.  However, it is much faster to use the AES-NI
instructions in userland than to use a system call that copies the data
into a kernel buffer, uses the sames AES-NI instructions, then copies the
data back out again along with the overhead of a pair of user <--> kernel
transitions.  If you have an actual crypto offload device (as in a PCI-e
card or something), then you might be interested in /dev/crypto (and we
should fix that eventually), but AES-NI is just faster software crypto and
is best done directly in userland.

-- 
John Baldwin

????????????????????????????????????????????????????????????????????????????

> On Dec 6, 2018, at 4:39 PM, John Baldwin <jhb at FreeBSD.org> wrote:
> 
> On 12/6/18 3:24 PM, John Nielsen wrote:
>>> On Dec 6, 2018, at 4:04 PM, Xin LI <delphij at gmail.com>
wrote:
>>> 
>>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen <lists at
jnielsen.net> wrote:
>>>> 
>>>> I have upgraded two physical machines from 11-STABLE to
12-STABLE recently (one is 12.0-PRERELEASE r341380 and the other is
12.0-PRERELEASE r341391). I noticed today that neither machine seems to be
utilizing /dev/crypto. Typically I see at least ssh/sshd have the device open
plus some programs from ports. But 'fuser' doesn't list any
processes on either machine:
>>>> 
>>>> # fuser /dev/crypto
>>>> /dev/crypto:
>>>> 
>>>> Both machines are running custom kernels that include
"device crypto" and "device cryptodev". One of them
additionally has "device aesni".
>>>> 
>>>> Is anyone else seeing this? Any idea what would cause it?
>>> 
>>> Your average OpenSSL applications should not use /dev/crypto, if
your
>>> goal is to utilize AES-NI (which does not require /dev/crypto).  On
>>> capable systems, AES-NI would be used automatically (and it's
faster
>>> this way).
>> 
>> Thanks for the response. Is there a way to verify that AES-NI is being
used for e.g. ssh? I'm also curious why/when/how the change to not use (or
support?) /dev/crypto from base openssl was made.
> 
> I suspect it was something we just didn't test in the flurry of other
work
> during the OpenSSL upgrade.
I did wonder about that. :)
> However, it is much faster to use the AES-NI
> instructions in userland than to use a system call that copies the data
> into a kernel buffer, uses the sames AES-NI instructions, then copies the
> data back out again along with the overhead of a pair of user <-->
kernel
> transitions.  If you have an actual crypto offload device (as in a PCI-e
> card or something), then you might be interested in /dev/crypto (and we
> should fix that eventually), but AES-NI is just faster software crypto and
> is best done directly in userland.
That makes sense and explains some other comments I was just reading. Is
aesni(4) even required if all you want is userland acceleration?