<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 11, 2017 at 2:00 PM, Robert Moskowitz <span dir="ltr"><<a href="mailto:rgm@htt-consult.com" target="_blank">rgm@htt-consult.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Gordon, thanks for the response.<br>
<br>
<div class="m_-5558247688859777704moz-cite-prefix">On 08/11/2017 08:42 AM, Gordan Bobic
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span style="font-size:12.8px">Most ARMs have
hardware crypto.</span>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">IIRC, aarch64 chips have AES
inline instruction like modern x86 CPUs. OpenSSL that ships
with CentOS aarch64 already takes advantage of this.</div>
</div>
</blockquote>
<br>
Maybe when I retire (could be as early as start of '19, but by start
of '21), I will move to aarch64 SoC. :)<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div style="font-size:12.8px">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.</div>
<div style="font-size:12.8px">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.</div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">To use this, you will need to:</div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">1) build and install this kernel
module:</div>
<div style="font-size:12.8px"><a href="http://cryptodev-linux.org/" target="_blank">http://cryptodev-linux.org/</a><br>
</div>
<div style="font-size:12.8px">2) Recompile your openssl package
with a modified ./configure line to enable cryptodev offload</div>
</div>
</blockquote>
<br>
I would like to think this is in the C7-armv7hl we are working
with...<br></div></blockquote><div><br></div><div>It applies to it, yes.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote type="cite">
<div dir="ltr">
<div style="font-size:12.8px">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.</div>
</div>
</blockquote>
<br>
I don't care so much about SSH. This is used occasionally for admin
work. https would be very frequent (and imaps, and ...). <br></div></blockquote><div><br></div><div><br></div><div>Anything that uses OpenSSL would benefit from it.</div><div>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.</div><div>I gave up on filing Fedora and RH bug reports and patches some time ago.</div><div><br></div><div><br></div><div><br></div></div></div></div>