ossl.4: Canonicalize HARDWARE and add powerpc64

[ziaee]

Summary

Fixes: 5daf8ed625af ("Add GCM support on powerpc64/powerpc64le")
MFC after: the above was scheduled to but has not mfc yet

[markj]

share/man/man4/ossl.4

86

This feels weird: OpenSSL provides an optimized software implementation of various cryptographic transforms. It doesn't depend on any particular hardware per se. The reason it supports only a subset of the platforms supported by FreeBSD is that the implementations are CPU-specific, and each one requires work to port to ossl. In other words, this isn't a hardware offload driver such as qat or safexcel, so the traditional hardware section of the driver manual doesn't make as much sense.

It would be somewhat useful to list the CPU features required for ossl to be usable on each of these platforms, like the aesni and armv8crypto pages do. What do you plan to do for those pages? I can help draft some corresponding text for ossl.

[ziaee]

share/man/man4/ossl.4

86

Those pages need hardware sections, because this year I was cleaning out lines from the original hardware notes in the 90s. The only way the hardware notes is maintainable is if everything is pulled in automatically. I don't really understand this stuff, so if you would help that would be amazing.

Related, attempting with armv8crypto document description - https://reviews.freebsd.org/D59730

[ngie]

Thank you @ziaee !

share/man/man4/ossl.4

86

Those pages need hardware sections, because this year I was cleaning out lines from the original hardware notes in the 90s. The only way the hardware notes is maintainable is if everything is pulled in automatically. I don't really understand this stuff, so if you would help that would be amazing.

Related, attempting with armv8crypto document description - https://reviews.freebsd.org/D59730

It really should be a table, but I think this is fine for making forward progress in this manpage.

[jhb]

I would actually like to just retire armv8crypto(4) and aesni(4) once ossl(4) is a superset. There's not really a compelling reason to have two separate AES-NI implementations of various algorithms, and it seems more prudent to me to reuse OpenSSL's work than reimplementing from scratch.

[ziaee]

Ok team, what do you want me to do? We can keep iterating on this (although this is the extent of my understanding) or I can merge this.

I would actually like to just retire armv8crypto(4) and aesni(4) once ossl(4) is a superset.

This is part of the motivation for this change.

[ngie]

@gallatin : please see @jhb 's comment about wanting to remove armv8crypto (related to D60097).