Re: AES leaks, cgd ciphers, and vector units in the kernel

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Thu, 18 Jun 2020 07:06:16 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> 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.