Implementing in-kernel AES crypto acceleration on ppc (POWER8+)

Hello,

Good to see this! I'll answer inline.

On Thu, 3 Aug 2023 12:51:57 -0500

Post by Shawn Anastasio
Hello all,
Raptor Engineering is interested in adding support for in-kernel AES
acceleration on ppc64 via the VMX crypto instructions added in ISA
2.07B, and I wanted to reach out to the community with a few
questions.

I would love to see this added.

Post by Shawn Anastasio
1. As I understand it, FreeBSD already has support for in-kernel
crypto acceleration on x86 and ARM via the aesni and armv8_crypto
drivers respectively that each implement the cryptodev interface. Am I
correct in understanding that adding AES acceleration for Power
would just involve creating another driver here, or are there other
pieces of the puzzle that I've missed?

John Baldwin can probably answer this better, but I think your
understanding is correct. There might be some plumbing needed as well,
but that should be minimal.

Post by Shawn Anastasio
2. I see that both the aesni and armv8 drivers make use of the
fpu_kern_enter/fpu_kern_leave functions to guard access to vector
registers, but it appears that these functions aren't implemented
on ppc. Is that correct, or does an in-kernel facility for safely
accessing vector registers on ppc already exist?

Nope, ppc doesn't have these facilities yet. It shouldn't be hard to
implement, we just haven't done it yet. If you're interested in
implementing them, you should be able to model it after arm64, largely.

Post by Shawn Anastasio
3. For the accelerated AES implementation itself, I've noticed that
cryptogams[*] contains an implementation that is both widely
deployed (and thus tested and likely to be correct) and also BSD
licensed. Would it be acceptable to import the relevant routines to
the FreeBSD kernel and have the new cryptodev driver simply call into
them, or are there other considerations involved?

I think the right way to do that would be to import the code as-is as
third party code, and call into the routines that you need. You can
#ifdef out the unneeded bits, but try to keep it as intact as possible
from upstream.

Post by Shawn Anastasio
4. Is there a userspace test framework for the cryptodev API that
could be used to validate and benchmark the new implementation, or
would I have to write that myself? It appears that OpenSSL had
support for /dev/crypto at one point, but I'm not sure that is the
case any longer.

John Baldwin might have some ideas here, too.

Post by Shawn Anastasio
My apologies for the large number of questions, but I look forward to
hearing back and working with the FreeBSD community to get this
implemented.
Thanks,
Shawn Anastasio
[*] https://github.com/dot-asm/cryptogams

- Justin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

John Baldwin

2023-08-04 14:55:50 UTC

Post by Justin Hibbits
Hello,
Good to see this! I'll answer inline.
On Thu, 3 Aug 2023 12:51:57 -0500

I would love to see this added.

John Baldwin can probably answer this better, but I think your
understanding is correct. There might be some plumbing needed as well,
but that should be minimal.

Recently for accelerated software crypto we have been using the existing
assembly routines from OpenSSL (which has ppc routines IIRC) in the
ossl(4) driver. For powerpc you would need to provide any ppc-specific
things the OpenSSL assembly routines need (e.g. on x86 they use an array
of words holding feature bits corresponding to output from cpuid), and
mostly just add build glue. This driver also requires fpu_kern_*, but
in general ossl(4) is preferred going forward and will eventually
replace aesni and armv8crypto entirely.

Yes, this is a prerequisite. If you implement this you can also enable
assembly for ZFS on powerpc as well.

As mentioned above, I would prefer using the OpenSSL sources already
in the tree via ossl(4).

John Baldwin might have some ideas here, too.

There is a cryptocheck tool in tools/tools/crypto that I tend to use.
It generates "random" but deterministic (since it uses a fixed seed
for libc's PRNG) tests of most of the algorithms supported by the
cryptodev API with various key sizes, nonce sizes, payload, and AAD
sizes. It performs each test once with OpenSSL's userland crypto
and a second time with /dev/crypto and compares the results reporting
any mismatches. There isn't a manpage, but there are some comments
in the source.

There are also some tests in the test suite that make use of the
NIST known answer test vectors (which have to be installed via a nist-kat
package).

--
John Baldwin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Shawn Anastasio

2023-08-04 16:13:42 UTC

Post by Justin Hibbits
Hello,
Good to see this! I'll answer inline.
On Thu, 3 Aug 2023 12:51:57 -0500

I would love to see this added.

John Baldwin can probably answer this better, but I think your
understanding is correct. There might be some plumbing needed as well,
but that should be minimal.

Thank you for pointing this out. It seems that sys/crypto/openssl
conveniently already has the relevant ppc assembly files imported from
the openssl source tree, so it looks like I'll just have to implement
the ppc-specific openssl glue, in addition to the fpu_enter/leave
functions.

Yes, this is a prerequisite. If you implement this you can also enable
assembly for ZFS on powerpc as well.

Makes sense, thank you both for the confirmation. I'll get started on
mocking up an implementation of these functions.

As mentioned above, I would prefer using the OpenSSL sources already
in the tree via ossl(4).

Sounds good.

John Baldwin might have some ideas here, too.

There is a cryptocheck tool in tools/tools/crypto that I tend to use.
It generates "random" but deterministic (since it uses a fixed seed
for libc's PRNG) tests of most of the algorithms supported by the
cryptodev API with various key sizes, nonce sizes, payload, and AAD
sizes. It performs each test once with OpenSSL's userland crypto
and a second time with /dev/crypto and compares the results reporting
any mismatches. There isn't a manpage, but there are some comments
in the source.
There are also some tests in the test suite that make use of the
NIST known answer test vectors (which have to be installed via a nist-kat
package).

Perfect, this seems like exactly what I was looking for.

I'll begin work on the fpu_enter/leave functions and keep you all
updated. Thank you both for the prompt and detailed responses!

- Shawn

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Shawn Anastasio

2023-08-21 23:03:49 UTC