[Arm-dev] Fwd: Re: Does openssl pick low level interface or high level interface to do encrypt?

Fri Aug 11 13:08:13 UTC 2017
Gordan Bobic <gordan at redsleeve.org>

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>