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

[Greg Troxel <gdt%lexort.com@localhost>]

Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

>> 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.)

What I meant is: consider an external USB disk of say 4T, which has a
cgd partition within which is ffs.

Someone attaches it to several systems in turn, doing cgd_attach, mount,
and then runs bup with /mnt/bup as the target, getting deduplication
across systems.  Of these systems, some are older NetBSD and some are
newer.  Posit one each netbsd 5, 7, 8, 9, current in the mix, as a blend
of strawman and not-so-crazy example.  After this, the disk is taken to
an undisclosed location where it is unlikely to be destroyed (or at
least, unlikely to be destroyed correlated with the main systems'
disks), but at which it does not have reliable physical protection
against snoooping.  I submit that this is not an odd model for cgd
usage.

(I don't actually do this; I mount disks on one system and do
over-the-network backups from the older systems, and my mix of system
versions is different.)

So, using the new faster cipher won't work, because it's not supported
by the older systems.

Hoewver, if the -current system does AES slowly because it has the new
constant-time implementation, and the older ones do it like they used
to, I don't see a real problem.

>> 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.

Yes, that's what I meant.  Kind of like "openssl speed".

> 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.

I did sort of mean "how many MB/s would the old impl do, and how many
MB/s would the new one do", realizing that actually reading/writing from
disk might overwhelem that.

I'm not sure my request is reasonable; it might help up the comfort
level for people.

> (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).)

So it remains to make userland AES use also constant time, as a separate
step?

>> 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.

I sort of meant putting the new code in there so it can be measured, but
I realize that's messy.

Please don't take my "is there a way" question as a demand.