Date: Wed, 26 Jun 2013 00:55:45 +0100 From: Joe Holden <lists@rewt.org.uk> To: Juli Mallett <jmallett@FreeBSD.org> Cc: "freebsd-mips@FreeBSD.org" <mips@freebsd.org> Subject: Re: AES-GCM/Hardware crypto for Octeon Message-ID: <51CA2E01.9070908@rewt.org.uk> In-Reply-To: <CACVs6=9f5AKrnbEw7QOOYOfu3rvKfDPxEf5M4%2BQwJgsbKHzMmg@mail.gmail.com> References: <51C9BFE6.20701@rewt.org.uk> <CACVs6=_y3NFo3Pq8cDy_JvqCqPcGhk-O%2B%2BOWHCT68F-rdwExbQ@mail.gmail.com> <51C9F56A.5070401@rewt.org.uk> <CACVs6=9f5AKrnbEw7QOOYOfu3rvKfDPxEf5M4%2BQwJgsbKHzMmg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Juli Mallett wrote: > On Tue, Jun 25, 2013 at 12:54 PM, Joe Holden <lists@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. > That explains that then! >> 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. > Someone lead me to believe the sdk was licensed as such, but it appears to actually be a 3-clause license - even better :) I've approached a few people about doing some work on it, but they aren't versed enough in either FreeBSD or crypto to actually achieve the (ideal) goal of having the full functionality available via cryptodev. >> 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. > Will have a look at those, I wasn't aware Mikrotik were using any Octeon hardware, cheers. >> 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. > Functionality avaialble via cryptodev would negate this requirement, right? The lack of /dev/crypto on Linux probably contributed to them doing it like that? >> 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. I need to double check EdgeOS, but I'd be surprised if they don't have RC4 support, especially considering the application for PPTP etc (which is why I have been playing with it for some applications, MPPE would benefit from it) > > Thanks, > Juli. Cheers, Joe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51CA2E01.9070908>