Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1968873ybi; Sun, 16 Jun 2019 18:23:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqyoNW2iF6QGDxeUx2rYni1pZwMGjICWrdMsGVyT6HzZqcq66A7WVA13KY0KuURvCQFg4H58 X-Received: by 2002:a17:90a:2430:: with SMTP id h45mr24304768pje.14.1560734613836; Sun, 16 Jun 2019 18:23:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560734613; cv=none; d=google.com; s=arc-20160816; b=fsm+yGey5iFa1/0waYrVwqWtA9lhMxe3TTrGAmnMgGD33BMuLpBol2sx7pAFvkrOq4 nT6TzUnj/NSVngnjwn88D3IPwqFhqqc+zQf5m8uKUmPbEiq+IeZcvUJwzQVdIYsWYXGE 5bQSJD+Ufpd57ZvjuL8GSCh2Mqdyy0kS4S/GzlnWIoNnpjgac/4s6dUiqkmXsFLUbvzf u/5tJY5SXBGU+GglsgXgrosh6S1gh+ZIIulQ0wNLjxEq0I5SueXOX55CHckPOloPUYcC EpzlFGke8Y/S/EVkwWAc4H/1XjqeHA6a7t74LLqYXyiD4Sq6JjV/N3JqoB1GHWoWkkMD yM4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=NvIJ8839SrWc+SN7hGWerIoI/csIgZQiwgsIoxi+fmc=; b=FQYiSc+EGGAO7/aW75dQqQyifapIWOfrqA68LlFW1BDUs7YLb8Orsh4vztxQ0Ditdh 44G1otwyl3+nb+nLso4t8pDRPWDY2kdy985qUdvmMgUX0usXui0xrFj2WNDkFe0v7ewR gXXYSSyP9BebijsBcOx1sAhnLa5KUd2SqMyovmYJ7Jf3ROVVJhq2rF7gTTlCWGGsDflJ nIdDOvYpKrxCQZWzBen8srdZ0iLdTu1LfenFxKTWuA/9qnEV/8m76OkzAzSghu85fLpw 6ZIFCPeWHHEkyrYs2EgiJgEHuSXrX/hUtAO9A+bhEV2gpAgg0d4eSyf/8m9sVvmUKpOL 6X4A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a17si9086986pfa.108.2019.06.16.18.23.12; Sun, 16 Jun 2019 18:23:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727465AbfFQBXJ (ORCPT + 99 others); Sun, 16 Jun 2019 21:23:09 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:34174 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727238AbfFQBXI (ORCPT ); Sun, 16 Jun 2019 21:23:08 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1hcgMV-00043D-2o; Mon, 17 Jun 2019 09:23:07 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hcgMH-0002MA-Gw; Mon, 17 Jun 2019 09:22:53 +0800 Date: Mon, 17 Jun 2019 09:22:53 +0800 From: Herbert Xu To: Ard Biesheuvel Cc: netdev@vger.kernel.org, linux-crypto@vger.kernel.org, ebiggers@kernel.org, edumazet@google.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, jbaron@akamai.com, cpaasch@apple.com, David.Laight@aculab.com Subject: Re: [PATCH v2] net: ipv4: move tcp_fastopen server side code to SipHash library Message-ID: <20190617012253.4hgfdwvurskstz4o@gondor.apana.org.au> References: <20190614140122.20934-1-ard.biesheuvel@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190614140122.20934-1-ard.biesheuvel@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Jun 14, 2019 at 04:01:22PM +0200, Ard Biesheuvel wrote: > Using a bare block cipher in non-crypto code is almost always a bad idea, > not only for security reasons (and we've seen some examples of this in > the kernel in the past), but also for performance reasons. > > In the TCP fastopen case, we call into the bare AES block cipher one or > two times (depending on whether the connection is IPv4 or IPv6). On most > systems, this results in a call chain such as > > crypto_cipher_encrypt_one(ctx, dst, src) > crypto_cipher_crt(tfm)->cit_encrypt_one(crypto_cipher_tfm(tfm), ...); > aesni_encrypt > kernel_fpu_begin(); > aesni_enc(ctx, dst, src); // asm routine > kernel_fpu_end(); > > It is highly unlikely that the use of special AES instructions has a > benefit in this case, especially since we are doing the above twice > for IPv6 connections, instead of using a transform which can process > the entire input in one go. > > We could switch to the cbcmac(aes) shash, which would at least get > rid of the duplicated overhead in *some* cases (i.e., today, only > arm64 has an accelerated implementation of cbcmac(aes), while x86 will > end up using the generic cbcmac template wrapping the AES-NI cipher, > which basically ends up doing exactly the above). However, in the given > context, it makes more sense to use a light-weight MAC algorithm that > is more suitable for the purpose at hand, such as SipHash. > > Since the output size of SipHash already matches our chosen value for > TCP_FASTOPEN_COOKIE_SIZE, and given that it accepts arbitrary input > sizes, this greatly simplifies the code as well. > > Signed-off-by: Ard Biesheuvel > --- > v2: rebase onto net-next > reverse order of operands in BUILD_BUG_ON() comparison expression > > include/linux/tcp.h | 7 +- > include/net/tcp.h | 10 +- > net/ipv4/tcp_fastopen.c | 97 +++++++------------- > 3 files changed, 36 insertions(+), 78 deletions(-) You should also revert commit 798b2cbf9227 in your patch: commit 798b2cbf9227b1bd7d37ae9af4d9c750e6f4de9c Author: David S. Miller Date: Tue Sep 4 14:20:14 2012 -0400 net: Add INET dependency on aes crypto for the sake of TCP fastopen. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt