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. 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 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. On Fri, Aug 11, 2017 at 1:08 PM, Robert Moskowitz <rgm at htt-consult.com> wrote: > How does OpenSSL work on ARM? > > Do any arms have hardware crypto? > > thanks > > > -------- Forwarded Message -------- > Subject: Re: [openssl-users] Does openssl pick low level interface or > high level interface to do encrypt? > Date: Thu, 10 Aug 2017 15:16:09 +0000 > From: Salz, Rich via openssl-users <openssl-users at openssl.org> > <openssl-users at openssl.org> > Reply-To: Salz, Rich <rsalz at akamai.com> <rsalz at akamai.com>, > openssl-users at openssl.org > To: openssl-users at openssl.org <openssl-users at openssl.org> > <openssl-users at openssl.org> > > What OpenSSL does is not necessarily obvious. The INSTALL document talks > about the no-asm configuration option. Details about what the assembler > code does in terms of optimization are only available by reading the source > code comments in the various Perl files that generate the assembler, mostly. > > > > On x86, the assembly code uses the CPUID instruction (see the > OPENSSL_ia32cap.pod manpage) to determine if various instructions (AES, > SSE, MMX, etc) are available and will use them if so. For other > processors, similar tests are performed if at all possible. > > > > I have added this to the FAQ > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz at jabber.at Twitter: RichSalz > > > > *From:* - JinsongJi [mailto:jjsbear at hotmail.com <jjsbear at hotmail.com>] > *Sent:* Wednesday, August 09, 2017 9:09 AM > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Does openssl pick low level interface or high > level interface to do encrypt? > > > > Hi, > > > > For one simple operation: openssl enc -aes-256-cbc -salt -in foo.txt -out foo.enc > > Does openssl pick classic implementation or AES-NI implementation to do > this encrypt? > > > > Does any user/application always pick classic implementation for AES > operation regardless of AES-NI improves speed much? > > > > Is there any document about this interface selection? > > > > Thanks, > > Jinsong > > _______________________________________________ > Arm-dev mailing list > Arm-dev at centos.org > https://lists.centos.org/mailman/listinfo/arm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20170811/80022265/attachment-0006.html>