> Date: Thu, 18 Jun 2020 07:06:16 -0400 > From: Greg Troxel <g...@lexort.com> > > For me, the main use of cgd is to encrypt backup drives. [...] > > I don't really see the new cipher as a reasonable option for removable > disks that need to be accessed by older systems. I can see it for > encrypted local disk. But given AES hardware speedup, I suspect most > people can just stay with AES.
Can you be more specific about the systems you're concerned about? What are the characteristics and performance requirements of the different systems that need to share disks? Do you have a reason to need to share a backup drive that you use on an up-to-date NetBSD on older hardware where it has to be fast, with a much older version of NetBSD? (I am sure there are use cases I haven't thought of; I just want to make sure I understand the use cases before I try to address them.) > Is there an easy way to publish code that does hardware AES, to allow > people to measure on their hardware? If a call for that on -users turns > up essentially zero actual people that would be bothered, I think that > would be interesting. I am not quite sure what you're asking. Correct me if I have misunderstood, but I suspect what you're getting at is: How can someone on netbsd<=9 test empirically whether this patch will have a substantial negative performance impact or not? On basically all amd64 systems of the past decade, and on most if not all aarch64 systems, there is essentially guaranteed to be a net performance improvement. What about other systems? The best way to test this is to just boot a new kernel and try a workload. But I assume you are looking for a userland program that one can compile and run to test it without booting a new kernel. I could in a couple hours make a program that checks cpuid to detect hardware support and does some measurements in isolation -- to estimate an _upper bound_ on the system performance impact. The upper bound is likely to be extremely conservative unless your workload is actually reading and writing zeros to cgd on a RAM-backed file in tmpfs; for a realistic impact on cgd or ipsec you would have to take into account the disk or network throughput -- the fraction of it that is spent in the crypto is what the 1/3-2/3 figure applies to. (Note that there is no impact on userland crypto, which means no impact on TLS or OpenVPN or anything like that, unless for some bizarre reason you've turned on kern.cryptodevallowsoft and the userland crypto uses /dev/crypto, the solution to which is to stop using /dev/crypto and/or turn off kern.cryptodevallowsoft for anything other than testing because it's terrible (and also the apparently boolean nature of kern.cryptodevallowsoft is a lie).) > I'm unclear on openssl and hardware support; "openssl speed" might be a > good home for this, and I don't know if openssl needs the same treatment > as cgd. (Fine to keep separable things separate; not a complaint!) OpenSSL is a mixed bag. It has a lot more MD implementations of various cryptographic primitives. But many of them are still leaky. So it's probably not a very good proxy for what the performance impact of this patch set will be.
