From owner-freebsd-mips@FreeBSD.ORG Tue Jun 25 20:04:43 2013 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3511646 for ; Tue, 25 Jun 2013 20:04:43 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF051220 for ; Tue, 25 Jun 2013 20:04:43 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id o10so1093580lbi.25 for ; Tue, 25 Jun 2013 13:04:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=rbvYeOE/M89Nqwue8PnGCE9ZX8C+tIikTsR4atk3DMg=; b=mUHi/5LhUKfY0vhN/9wYN/bkX97DL2k1Gw8AYGiniwVczsixx1Sb8qn9vNRuwBivr4 elbzauDh5IZ4gGEKZuaadaFnqiVLSSRTiqkAesjW+7MsZeDfnnCRBalYu5IzKwhEAIr8 axWVdRNmxfFc+wK3rzJqyOziqbQxH3UOupnyEkOKf6or51fANaGcWe619FG08O4cLcuv b9JEnjEN8oinuZrGKRkSv9bOBfaIVZCUNUegXGjkx70X0oHn92M+X4TiT9M2Yv+dUxi6 1Xs4dlxHn81/qG+PDBzCV6+TxQP+14wzP+omjt4487zA39sQmfPPjN8Z6Aa1nJxsmBLb uyXQ== X-Received: by 10.112.52.97 with SMTP id s1mr663653lbo.8.1372190682016; Tue, 25 Jun 2013 13:04:42 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.113.231 with HTTP; Tue, 25 Jun 2013 13:04:21 -0700 (PDT) In-Reply-To: <51C9F56A.5070401@rewt.org.uk> References: <51C9BFE6.20701@rewt.org.uk> <51C9F56A.5070401@rewt.org.uk> From: Juli Mallett Date: Tue, 25 Jun 2013 13:04:21 -0700 X-Google-Sender-Auth: KZGsSNl8Mgk9kLaNLbik6RwpB9M Message-ID: Subject: Re: AES-GCM/Hardware crypto for Octeon To: Joe Holden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlpEmDlZ+xp80fyF16csfYppcK1xAxKCrW2CsK2qYX47n3Qfd9dZ6LkSbKYoi2+wsUMzgMK Cc: "freebsd-mips@FreeBSD.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:04:43 -0000 On Tue, Jun 25, 2013 at 12:54 PM, Joe Holden 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 fo= r > 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 RC= 4. > 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 s= ame > 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: > > =E2=80=A2 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 parti= al > 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 wh= at > 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.0= 5k > > 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.3= 9k > > 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.