AES-GCM/Hardware crypto for Octeon

[Juli Mallett]

On Tue, Jun 25, 2013 at 12:54 PM, Joe Holden <lists at rewt.org.uk> wrote:
> Juli Mallett wrote:
>>
>> Rather than using a cryptodev, you can actually use the crypto
>> coprocessor from userland.  I remember looking at AES-GCM once, and I
>> think it includes some instructions or coprocessor features that make
>> implementing GCM easier, but it's not like the hardware will directly
>> do AES in Galois Counter Mode for you.  I could be misremembering.
>>
>> If you look at the cvmx-asm.h file in sys/contrib/octeon-sdk you can
>> see what the interfaces for crypto offload are like, and you can see
>> (somewhat convoluted) sample code using them in
>> sys/mips/cavium/cryptocteon.  There are patches to OpenSSL to use the
>> crypto coprocessor directly, but they're certainly not in our tree,
>> and I don't think there's a version of OpenSSL that ships with them.
>>
>> Are you just wanting AES-GCM to go faster across the whole OS, with
>> SSH, etc., or do you have a specialized application that you want it
>> for?  If the latter, I'd encourage you to consider getting someone to
>> throw together code to use the crypto coprocessor that's tailored to
>> your application.
>>
> Well, at present I can't see the hardware crypto being used, even with
> -engine cryptodev, unless the coprocessor is slower than a 1.8ghz atom for
> RC4 (which Cavium seem to indicate is supported by their SSL stuff, the
> product brief isn't specific though,
> http://www.cavium.com/css_ssl_sof_stk.html).

We only have offload support in kernel for block ciphers and hashes, not RC4.

> Unless of course support for
> these isn't included in the GPL sdk, which wouldn't surprise me.

You're buying Cavium's marketing a little too much :)  The cnusers SDK
includes everything needed to access (very nearly) all of the offload
features, but it provides very primitive interfaces to do so.  For
kernel support, Cavium doesn't provide anything; we're currently using
modified drivers from the Linux OCF port which make use of those
primitive interfaces.  Adding support for others is fairly easy.
Cavium does provide a modified OpenSSL that's not part of the cnusers
distribution, but it doesn't do anything special or exciting; anyone
who has written crypto code could bang out an OpenSSL engine for
Octeon in a week.  Doing something one-off that's specific to an
application is even easier.

> In particular I was after support for openvpn, which should support the same
> ciphers as openssl supports - but openssl doesn't use the hardware for
> aes-gcm as you say.  I'm going off the product brief which says:
>
> • Support for IPsec, SSL, DH, SRTP, WLAN security,
>  DES, 3DES, AES (up to 256-bit including GCM),
>  SHA1, SHA-2 up to SHA-512, RSA, ECC, KASUMI,
>  and Data-at-rest security (AES-XTS)
>
> which would imply that AES-GCM is supported in hardware but again isn't
> specific as to what is actually done in hardware and what is just a partial
> helper.

Look at Mikrotik's patches to OpenVPN.  I recall there being some
trivial things around Octeon offload in their OpenSSL or their
OpenVPN, but I can't recall right now.

> WRT RC4, the output I've got from openssl speed don't quite tally with what
> I'd expect:
>
> erl2# openssl speed -engine cryptodev:
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> rc4              17156.32k    21248.94k    22636.75k    23062.56k 23180.05k
>
> same on an atom minus cryptodev:
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> rc4              66027.12k    84307.30k    90219.81k    92061.93k 92585.39k
>
> The things I'd expect to be faster are much, much faster, eg aes-128-cbc, I
> also see similar for SHA1 et al, which is specifically supported by their
> SSL stuff.  I'm not clued up with what is/isn't supported by the GPL sdk
> though.

Again, the "GPL sdk" (which isn't GPL'd) has nothing to do with this
really.  Even if Cavium's OpenSSL is available under a license we can
use (and I think it isn't, but I've never looked seriously), the
changes were added fairly invasively, and one would nearly be better
off doing a from-scratch implementation anyway.

> Looking at the code for cryptoctean, would registering other supported
> methods do the trick, or does it require extra code to actually work?

It requires actual implementation of the required offload support.
You could reach out to the ocf-linux-users mailing list or David
McCullough directly to see if there's patches to the cryptocteon code
to add RC4 support.  I'm sure someone else has done it already, but
whether they're interested in sharing their sources is likely a
different question.

Thanks,
Juli.