Add qat(4)

[markj]

Summary

This diff provides an Intel QAT driver and opencrypto interface
implementation. The driver was ported from NetBSD, which in turn seems
partially based on the (BSD-licensed) Linux QAT driver. I made a number
of changes:

• modifications to support the new opencrypto interface in head
• support for GMAC/AES-GCM, AES-CTR and AES-XTS
• support for detaching the driver
• various bug fixes
• DH895X support

A couple of things are not implemented yet but are in progress:

• separate input and output buffers (done separately to simplify an initial merge to stable/12)

[allanjude]

Do you know if it is possible to do SHA512/256 (SHA512 truncated to 256 bits, but it uses a different initial state)?

[markj]

In D26963#601481, @allanjude wrote:

Do you know if it is possible to do SHA512/256 (SHA512 truncated to 256 bits, but it uses a different initial state)?

I think it should be possible. For plain SHA transforms the initial state is passed in the content descriptor, and the driver can handle the truncation. Does opencrypto have a way to request SHA512/256?

[jhb]

OCF does not currently have algorithms for SHA 512/256 or SHA 512/224. It does support SHA 224 (which is SHA 256/224) and SHA 384 (which is SHA 512/384). Adding support for additional algorithms is fairly straightforward. You would need to add constants and simple software versions (as we always want a fallback so kernel consumers can depend on an algorithm existing) and ideally tests in cryptocheck. Ideally there would be at least one in-kernel consumer for an algorithm though. I think the use case for SHA 512/256 is ZFS?

[markj]

Lots of fixes and cleanups, especially for C2XXX hardware.