<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>