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@openssl.org Reply-To: Salz, Rich rsalz@akamai.com, openssl-users@openssl.org To: openssl-users@openssl.org openssl-users@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
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@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@openssl.org openssl-users@openssl.org Reply-To: Salz, Rich rsalz@akamai.com rsalz@akamai.com, openssl-users@openssl.org To: openssl-users@openssl.org openssl-users@openssl.org openssl-users@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@jabber.at Twitter: RichSalz
*From:* - JinsongJi [mailto:jjsbear@hotmail.com jjsbear@hotmail.com] *Sent:* Wednesday, August 09, 2017 9:09 AM *To:* openssl-users@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@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
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...
- 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 ...).
On Fri, Aug 11, 2017 at 1:08 PM, Robert Moskowitz <rgm@htt-consult.com mailto:rgm@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@openssl.org> <mailto:openssl-users@openssl.org> Reply-To: Salz, Rich <rsalz@akamai.com> <mailto:rsalz@akamai.com>, openssl-users@openssl.org <mailto:openssl-users@openssl.org> To: openssl-users@openssl.org <mailto:openssl-users@openssl.org> <openssl-users@openssl.org> <mailto:openssl-users@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@jabber.at <mailto:richsalz@jabber.at> Twitter: RichSalz *From:*- JinsongJi [mailto:jjsbear@hotmail.com] *Sent:* Wednesday, August 09, 2017 9:09 AM *To:* openssl-users@openssl.org <mailto:openssl-users@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@centos.org <mailto:Arm-dev@centos.org> https://lists.centos.org/mailman/listinfo/arm-dev <https://lists.centos.org/mailman/listinfo/arm-dev>
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
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.
-
Gordan Bobic -
Robert Moskowitz