maintaining CRYPTO_TIMING

[John Baldwin]

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