On Fri, Aug 11, 2017 at 2:00 PM, Robert Moskowitz rgm@htt-consult.com wrote:
Gordon, thanks for the response.
On 08/11/2017 08:42 AM, Gordan Bobic wrote:
Most ARMs have hardware crypto.
IIRC, aarch64 chips have AES inline instruction like modern x86 CPUs. OpenSSL that ships with CentOS aarch64 already takes advantage of this.
Maybe when I retire (could be as early as start of '19, but by start of '21), I will move to aarch64 SoC. :)
On armv7hl and earlier, they typically come with an asynchronous crypto coprocessor. What this does is allows the application to provide a source data pointer, key, and target data pointer, and waits for the co-processor to do it's thing. The upshot of this is what while the process is iowaiting for the response, the kernel can schedule other things requiring CPU time to run, so the main CPU can be productively busy while something else is doing the crypto. On a Marvell Kirkwood, the crypto throughput of this co-processor is approximately the same as what the main CPU can produce, but does so while consuming less power and leaving the CPU free to do other things, potentially doubling the throughput.
To use this, you will need to:
- build and install this kernel module:
http://cryptodev-linux.org/ 2) Recompile your openssl package with a modified ./configure line to enable cryptodev offload
I would like to think this is in the C7-armv7hl we are working with...
It applies to it, yes.
- Rebuild openssh package to back out RedHat's audit patch because it
breaks things horribly. IIRC (it's been a while since I worked on this), RH's audit patch adds functionality to store the session crypto keys used in the audit log for debugging. Unfortunately, once you have passed the crypto keys to the crypto coprocessor, you cannot get to them, so the code attempts the equivalent of use-after-free, which (thankfully) fails and crashes sshd. In reality what you are much better off doing is creating a SRPM of a clean vanilla latest upstream openssh source and just using that, without any broken distro patches getting in the way.
I don't care so much about SSH. This is used occasionally for admin work. https would be very frequent (and imaps, and ...).
Anything that uses OpenSSL would benefit from it. Unfortunately, last time I checked, RH specifically build OpenSSL with hardware acceleration support, but then go out of their way to ensure that it won't work if used, with things like the OpenSSH audit patch. I gave up on filing Fedora and RH bug reports and patches some time ago.