On Fri, Aug 11, 2017 at 2:00 PM, Robert Moskowitz <rgm at 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: > > 1) 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. > > 3) 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20170811/8d7f05ff/attachment-0006.html>