> 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.
On Thu, Dec 6, 2018 at 3:24 PM John Nielsen <lists at jnielsen.net> 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.You can disable the use of AES by passing environment variable OPENSSL_ia32cap and compare the speed, e.g.: OPENSSL_ia32cap="~0x200000000000000" openssl speed -evp aes-128-cbc (disabled bit 57, or ~0x200000000000000 means to disable the AES-NI capability bit). On most systems, using AES-NI is about twice fast, personally I don't really see a reason why people would want to disable it in production (even for security reasons), though, but yes there is an option. Cheers,
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 18. 12. 6., 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.OpenSSL 1.1.1 removed the old cryptodev: https://svnweb.freebsd.org/base/vendor-crypto/openssl/dist/CHANGES?revision=340690&view=markup#l400 Instead, OpenSSL added devcrypto engine for Linux: https://github.com/openssl/openssl/commit/619eb33 and added BSD support: https://github.com/openssl/openssl/commit/4f79aff then, completely removed BSD-specific cryptodev: https://github.com/openssl/openssl/commit/f39a550 However, it is disabled by default. Theoretically, it is functionally equivalent but it wasn't tested much. I can enable the new engine on head if many users request 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/20181206/011cc9be/attachment.sig>