Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp6888981imm; Wed, 27 Jun 2018 15:29:59 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKwLIITGVBpcW9VHvwIxAAuRObyTJcZtYcy9pBVpXeDDB0SRyIFyeoLvIhMl+y5pVRAXU0G X-Received: by 2002:a17:902:bccc:: with SMTP id o12-v6mr7867603pls.169.1530138599841; Wed, 27 Jun 2018 15:29:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530138599; cv=none; d=google.com; s=arc-20160816; b=ORym5VA+oO6QmZd1bwpLUkJZ7zRKchx+2a6ATFcVLO69JNOf7r8p5HRZCIE+K+I7nx qED0jXdrl5czG5Prt2PgllomkLijWNKkNN2a3ZrQELH9K52APWCqyWDEk2bbhZv7fb3i aFYUSWkKfZ4E6P/f6soUNAvhKC9yjLHgCJdV0Ai9LpGmUzavmGquhc19uvl94v2GilWg dyPyKKLjmEJZ1uqN5QT2AH/yGDU27PfF7CZg+Fao1d5SbIG7JDg/SmRK1KU0mLnQ1qox yLPpRGPv5Cb+9k+aYDKk+ZLBotIwO1L+PfTNQM8DGXHTuAkZUI9pJeWCHSdpZl7+e/Pf UUlg== 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:arc-authentication-results; bh=Rmdc7czVSkdrjGnEidmrhBy4g742OR+d7B7L8Xo3MOQ=; b=mec4BLidkZKpJ/azr6hTm1nxG4dqZXiI43wHMSB/pBvzrv14iNw7GLa84lTrZnL7BB iv8ODZqMrVn6fRcX7ACzUrBqzTPnVPoKO+K1ix42ywtsUbE00vl7mHGNvTcXeJFphVpf uApmhQllxuqZNWxVhzZQslzYkfDlU7aH7pttnVe4DU/EFe2gPVm+lbpRAjrgRxp+LD9V 272PkiRJeroLgPYrDSu2mQhId/EoBlVDr2iB3FiSzarR6MzkX7wbqX++0HvcemcLms4w i3zVBeObMzQyIqCreLcaAM/1B503nhGvt//gi609r6tX81Fksn+5vzBoTvy02gc0Gz0r Bivg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 o9-v6si4937188plk.434.2018.06.27.15.29.45; Wed, 27 Jun 2018 15:29:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966463AbeF0W2Z (ORCPT + 99 others); Wed, 27 Jun 2018 18:28:25 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:49638 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966251AbeF0W2X (ORCPT ); Wed, 27 Jun 2018 18:28:23 -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 1fYIuu-0000yI-17; Thu, 28 Jun 2018 06:28:00 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1fYIuj-0004D7-G8; Thu, 28 Jun 2018 06:27:49 +0800 Date: Thu, 28 Jun 2018 06:27:49 +0800 From: Herbert Xu To: Kees Cook Cc: "David S. Miller" , linux-crypto , "Gustavo A. R. Silva" , Arnd Bergmann , Eric Biggers , Alasdair Kergon , Giovanni Cabiddu , Lars Persson , Mike Snitzer , Rabin Vincent , Tim Chen , qat-linux@intel.com, dm-devel@redhat.com, LKML Subject: Re: [PATCH v2 11/11] crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK Message-ID: <20180627222749.xa5333caq5vaa7st@gondor.apana.org.au> References: <20180625211026.15819-1-keescook@chromium.org> <20180625211026.15819-12-keescook@chromium.org> <20180626092041.mxfg4lxcvxfivzc2@gondor.apana.org.au> <20180627143622.ntksjxsymo4yw6dz@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 27, 2018 at 11:31:09AM -0700, Kees Cook wrote: > > I might be catching on... so from this list, I should only "count" the > synchronous ones as being wrappable? The skcipher list is actually > pretty short: > > crypto/cryptd.c: crypto_skcipher_set_reqsize( > crypto/cryptd.c- tfm, sizeof(struct > cryptd_skcipher_request_ctx)); cryptd is async so you don't have to include it. > These are "simple" wrappers: > > crypto/lrw.c: crypto_skcipher_set_reqsize(tfm, > crypto_skcipher_reqsize(cipher) + > crypto/lrw.c- sizeof(struct rctx)); > > crypto/simd.c- reqsize = sizeof(struct skcipher_request); > crypto/simd.c- reqsize += crypto_skcipher_reqsize(&cryptd_tfm->base); > crypto/simd.c: crypto_skcipher_set_reqsize(tfm, reqsize); simd is async. > crypto/xts.c: crypto_skcipher_set_reqsize(tfm, > crypto_skcipher_reqsize(child) + > crypto/xts.c- sizeof(struct rctx)); > > But what are the "legitimate" existing crypto_skcipher_reqsize() values here? > > These are "complex" wrappers, with cts even adding blocksize to the mix... > > crypto/ctr.c- align = crypto_skcipher_alignmask(tfm); > crypto/ctr.c- align &= ~(crypto_tfm_ctx_alignment() - 1); > crypto/ctr.c- reqsize = align + sizeof(struct crypto_rfc3686_req_ctx) + > crypto/ctr.c- crypto_skcipher_reqsize(cipher); > crypto/ctr.c: crypto_skcipher_set_reqsize(tfm, reqsize); > > crypto/cts.c- align = crypto_skcipher_alignmask(tfm); > crypto/cts.c- bsize = crypto_skcipher_blocksize(cipher); > crypto/cts.c- reqsize = ALIGN(sizeof(struct crypto_cts_reqctx) + > crypto/cts.c- crypto_skcipher_reqsize(cipher), > crypto/cts.c- crypto_tfm_ctx_alignment()) + > crypto/cts.c- (align & ~(crypto_tfm_ctx_alignment() - 1)) + bsize; > crypto/cts.c- > crypto/cts.c: crypto_skcipher_set_reqsize(tfm, reqsize); > > What values might be expected here? It seems the entire blocksize > needs to be included as well... But otherwise yes these are the ones that count. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt