From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH v8 0/9] crypto: Remove VLA usage Date: Mon, 3 Sep 2018 22:50:41 -0700 Message-ID: References: <20180807211843.47586-1-keescook@chromium.org> <20180904051905.a2vyzijz6xyxvyhb@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Giovanni Cabiddu , LKML , Arnd Bergmann , Mike Snitzer , Tudor-Dan Ambarus , Rasmus Villemoes , Ard Biesheuvel , Will Deacon , qat-linux@intel.com, Matthew Wilcox , "David S. Miller" , "Gustavo A. R. Silva" , device-mapper development , Eric Biggers , David Woodhouse , Geert Uytterhoeven , Andrew Morton , Thomas Gleixner , Alasdair Kergon , linux-crypto To: Herbert Xu Return-path: In-Reply-To: <20180904051905.a2vyzijz6xyxvyhb@gondor.apana.org.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com List-Id: linux-crypto.vger.kernel.org On Mon, Sep 3, 2018 at 10:19 PM, Herbert Xu wrote: > On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote: >> v8 cover letter: >> >> I continue to hope this can land in v4.19, but I realize that's unlikely. >> It would be nice, though, if some of the "trivial" patches could get taken >> (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repeating them. >> *fingers crossed* >> >> Series cover letter: >> >> This is nearly the last of the VLA removals[1], but it's one of the >> largest because crypto gets used in lots of places. After looking >> through code, usage, reading the threads Gustavo started, and comparing >> the use-cases to the other VLA removals that have landed in the kernel, >> I think this series is likely the best way forward to shut the door on >> VLAs forever. >> >> For background, the crypto stack usage is for callers to do an immediate >> bit of work that doesn't allocate new memory. This means that other VLA >> removal techniques (like just using kmalloc) aren't workable, and the >> next common technique is needed: examination of maximum stack usage and >> the addition of sanity checks. This series does that, and in several >> cases, these maximums were already implicit in the code. >> >> This series is intended to land via the crypto tree for 4.19, though it >> touches dm, networking, and a few other things as well, since there are >> dependent patches (new crypto #defines being used, etc). > > I have applied patches 1-4 and 6-8. I'd like to get an ack from > the dm folks regarding patch 5. As to patch 9, please fix it so > it doesn't rely on the BUG_ON to catch things. Great! Thanks very much. I'll get a patch prepared to plumb crypto_skcipher_set_reqsize() failures. -Kees -- Kees Cook Pixel Security