Date: Fri, 12 Jun 2020 13:12:39 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: maintaining CRYPTO_TIMING Message-ID: <5e5c9bc6-ffec-cb50-920c-777ecefb917a@FreeBSD.org> In-Reply-To: <20200612195619.GA14376@raichu> References: <20200612161401.GA3992@raichu> <37f0c691-f067-20e5-2c21-7513fbdc0380@FreeBSD.org> <20200612195619.GA14376@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/12/20 12:56 PM, Mark Johnston wrote: > On Fri, Jun 12, 2020 at 12:46:27PM -0700, John Baldwin wrote: >> On 6/12/20 9:14 AM, Mark Johnston wrote: >>> Hi, >>> >>> I noticed that the opencrypto framework maintains counters for various >>> operations. These counters are all global and are updated >>> non-atomically, so they aren't SMP-friendly and won't be precise. I >>> wrote a patch to convert them to counter(9), which fixes both issues, >>> and I note that kern.crypto_stats was renamed to kern.crypto.stats in >>> HEAD so presumably we can use this opportunity to break the sysctl ABI >>> as well (the counters have to be widened from 32 bits to 64 bits). >>> Nothing in the base system seems to actually fetch these counters >>> outside of some code under tools/, which wasn't updated when the sysctl >>> was renamed. >> >> I think this is fine. I'd probably not oppose just removing the stats >> outright though. Not clear to me how useful they really are (I've never >> used them, always used dtrace or other stats that are more specific) > > I think the current stats are not particularly useful, but I could > imagine adding stats that might be. For instance, a counter for failed > CRYPTO_OP_VERIFY_DIGEST operations, or for operations handled by > software drivers vs. hardware drivers. I noticed while testing GELI > with a WIP driver that I had forgotten to implement AES-XTS+HMAC, so the > tests were causing GELI to fall back to a software implementation. > Counters could perhaps make it easier to spot cases where a consumer is > unexpectedly using an unaccelerated implementation. Or is there already > an easy way to spot that? I use a dtrace script for that sort of thing: https://github.com/bsdjhb/kdbg/blob/master/dtrace/crypto_drivers.d I have other dtrace scripts I haven't committed that are also useful (like printing out the 'csp' when creating sessions) For ccr I added counters for specific types of operations (ETA, GCM, CCM, cipher, and digest) that I also used when working on ccr(4). KTLS also has its own counters for ktls_ocf for TLS 1.2 vs 1.3. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5e5c9bc6-ffec-cb50-920c-777ecefb917a>