Date: Tue, 25 Jun 2013 20:54:18 +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: <51C9F56A.5070401@rewt.org.uk> In-Reply-To: <CACVs6=_y3NFo3Pq8cDy_JvqCqPcGhk-O%2B%2BOWHCT68F-rdwExbQ@mail.gmail.com> References: <51C9BFE6.20701@rewt.org.uk> <CACVs6=_y3NFo3Pq8cDy_JvqCqPcGhk-O%2B%2BOWHCT68F-rdwExbQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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). Unless of course support for these isn't included in the GPL sdk, which wouldn't surprise me. 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. 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. Looking at the code for cryptoctean, would registering other supported methods do the trick, or does it require extra code to actually work? Thanks, Joe > Thanks, > Juli. > > On Tue, Jun 25, 2013 at 9:05 AM, Joe Holden <lists@rewt.org.uk> wrote: >> Hi, >> >> Is the hardware crypto used by OpenCrypto/OpenSSL on the Octeon Plus range? >> Other than specifying cryptodev engine, is there a way to make sure that >> it's being used? >> >> Also, according to the Cavium product brief, the coprocessor supports >> AES-GCM, I can't work out if it's actually supported in OpenSSL as the >> patches seem to be geared towards Intel's hardware assisted variant - is >> this supportable on the current tree, or will it require extra patches/work >> (perhaps upstream?) >> >> Cheers, >> Joe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51C9F56A.5070401>