From owner-freebsd-stable@freebsd.org Thu Dec 6 23:48:39 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 700EB131B191 for ; Thu, 6 Dec 2018 23:48:39 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D92516BE83; Thu, 6 Dec 2018 23:48:38 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [10.3.135.19] (50-207-240-162-static.hfc.comcastbusiness.net [50.207.240.162]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id wB6NmZEd053264 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Dec 2018 16:48:37 -0700 (MST) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host 50-207-240-162-static.hfc.comcastbusiness.net [50.207.240.162] claimed to be [10.3.135.19] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: /dev/crypto not being used in 12-STABLE From: John Nielsen In-Reply-To: <0b3d8b81-4ed2-e900-9f0e-46ac7006a705@FreeBSD.org> Date: Thu, 6 Dec 2018 16:48:35 -0700 Cc: FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: References: <0b3d8b81-4ed2-e900-9f0e-46ac7006a705@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: D92516BE83 X-Spamd-Result: default: False [-2.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.936,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[jnielsen.net]; NEURAL_HAM_LONG(-0.99)[-0.988,0]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx0.freebsdsolutions.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.66)[-0.662,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(0.07)[asn: 6364(0.45), country: US(-0.09)]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 23:48:39 -0000 > On Dec 6, 2018, at 4:39 PM, John Baldwin wrote: >=20 > On 12/6/18 3:24 PM, John Nielsen wrote: >>> On Dec 6, 2018, at 4:04 PM, Xin LI wrote: >>>=20 >>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen = wrote: >>>>=20 >>>> 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: >>>>=20 >>>> # fuser /dev/crypto >>>> /dev/crypto: >>>>=20 >>>> Both machines are running custom kernels that include "device = crypto" and "device cryptodev". One of them additionally has "device = aesni". >>>>=20 >>>> Is anyone else seeing this? Any idea what would cause it? >>>=20 >>> 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). >>=20 >> 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. >=20 > 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?