Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5351084imm; Tue, 26 Jun 2018 09:46:14 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI7FIixm9ql7IREbJjFRmb9V/Z8vtxwuvAFTERZJ50RhNUrUmUiYk/KM3HiHiDohBzwQzGq X-Received: by 2002:a63:8c10:: with SMTP id m16-v6mr2125821pgd.120.1530031574735; Tue, 26 Jun 2018 09:46:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530031574; cv=none; d=google.com; s=arc-20160816; b=0VNM7tJzB3NkUApOP228d3zoS0cL2EJF0Tbrq0WzATNbhmQsceD6RGAUHE/lit5WP/ RepL4TATcqvDBHDEXCjZMpRWpNTszlIhk6AF7jqGiyQQ/JEat8lDZtaWSXd9/v0sIBwz UMGtoDyvlrrGwsV63XuZG6Ig7v4UmzVyFdMTtZR1x7tJglCxjsV0kxXd311I+O5RV/DO cRx6eYqsVk/9teCsi4dh8cHjIfx5Z+Pru3K4Gem5Vyr0kWx+epEQ42MxjhkMD7wcPUud AsMB30KRl8dLo6nZeXfn1Co54qVHG3q4k7zcgZdGbBwRndQ/P5m4RDGy/9gxkBmZAvtY 1eEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=f3P/2GUaNNmyvgMsxP0iPouVUKbOuGn2h38+V/ujWzw=; b=uxjE5TZi1H1BdkB9WRlRwPWhd2g2JLPpFyvL9pi7IB8EVb4d2lpvOfisrYxA7zO1pE PEkPMHJLMUjefUB8OAhofY7AHlHQtryxhztIhVi/o0CxKRdIRQRatKpLXIEb+QK+r3Hz AvVR+yA4aeoZyhL3Lddn5ZIPrZ4N6PKlVG8qq94XDFDlQN0Tw8GNOS+Ni905j3PTQRQ/ tU31sIAqmDBM/2lpTEXOPtmGi8W/lG6WQs/s7fzQdd36H0QMpQ0sxSdNlIgF29q2tKW6 r5su8edVY+G+IaObAjxH0Z5qLTa4gRJiya4plcp2gY1ipZoHdk1XgGXk74K4mmYC8TgR 98Dg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=rWS0zCXH; dkim=fail header.i=@chromium.org header.s=google header.b=C+Gtd+V2; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a11-v6si1845394pfo.68.2018.06.26.09.45.59; Tue, 26 Jun 2018 09:46:14 -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; dkim=fail header.i=@google.com header.s=20161025 header.b=rWS0zCXH; dkim=fail header.i=@chromium.org header.s=google header.b=C+Gtd+V2; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752627AbeFZQpP (ORCPT + 99 others); Tue, 26 Jun 2018 12:45:15 -0400 Received: from mail-yb0-f195.google.com ([209.85.213.195]:41971 "EHLO mail-yb0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752215AbeFZQpK (ORCPT ); Tue, 26 Jun 2018 12:45:10 -0400 Received: by mail-yb0-f195.google.com with SMTP id y187-v6so5886334yby.8 for ; Tue, 26 Jun 2018 09:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=f3P/2GUaNNmyvgMsxP0iPouVUKbOuGn2h38+V/ujWzw=; b=rWS0zCXHaP2r74M+VXMM+nEKYGI0ZWERpEq6TLQrX8diZp5wvZgT9N8yCndXyVBhsS KlLYig0SeYeo4T4r6jUxubRdIo2uYMHuiTYUT1KabJpf+ftO1NQuresCI4tmgxvQoVcz iZnUg6E7lefBWSuVl1APU1t8uDfZRMznQyZAoZZJ4ay6QksjO0/h76BxmomAqMeMvfkx Y7mhYaJK/nlZ9kNbMXLSH/IgDEydGQzAQP+j5DYPqXAA7n4H1X0q3pNEEhCT19+hLzzI VllRsLYS2KKEhFYsb09Jo7B425aodzEYdDSaHgLOlfmNU8g0/xKEy3cG64UTOG0ZiE4n TeIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=f3P/2GUaNNmyvgMsxP0iPouVUKbOuGn2h38+V/ujWzw=; b=C+Gtd+V2jlPBByLTMq71NCJtocHi2ZkQOitdKDNh6JoaOIwIhCZ69Skr6IF3EG5P0V Nc+x3NMtWAbTDfhT8+WEa+Apod1YM589jUNc/hThUxUk3bDh6aCrRlSW9PuA7icYqAjY vxx6IuRTyOrzQlxwjLgbThZlmsmQW9yspre+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=f3P/2GUaNNmyvgMsxP0iPouVUKbOuGn2h38+V/ujWzw=; b=Kr9v09GK5Pb8nIBdgqOOPP2IbbERKuuQqOZLgVOCYiNj+gaTXZstL9cYyjVSoO2RVx YIJuv+T5qGJICI3v6t4q6wKC8ZKXCAL/d/qWuB13uBYGRiTxGuFrXEx6VrAb2SVMItby FDC5iYATSdtKz2f7rMEaVSMC5ODsMkabS2LownGdLARdQSFNfbvcE/qfgLVgMuCT57Us sBsbLXBBM/x0UQfoo0PfPaQ9qChxoROV+j0r3GSqKV5Ix2bMMDXPKqgn6dq5eKz+u6NU PhvUPO9PfGAmrELEtxXdp0H18JvwBTar9R/NmIhgAcmYqy82TP5D/taq5nARNP31hLAB t34g== X-Gm-Message-State: APt69E1uFyunO+FAo2WUaQsJcfEpwiMQEQzaeYS5W3xD9xNh5Zj8AAmY woPPRT/nopqthfqbjNVTHsbCMabM970KpZTf275Siw== X-Received: by 2002:a25:ce8b:: with SMTP id x133-v6mr1175320ybe.118.1530031510024; Tue, 26 Jun 2018 09:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5f51:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 09:45:09 -0700 (PDT) In-Reply-To: <20180626092041.mxfg4lxcvxfivzc2@gondor.apana.org.au> References: <20180625211026.15819-1-keescook@chromium.org> <20180625211026.15819-12-keescook@chromium.org> <20180626092041.mxfg4lxcvxfivzc2@gondor.apana.org.au> From: Kees Cook Date: Tue, 26 Jun 2018 09:45:09 -0700 X-Google-Sender-Auth: aoBJ25LblkmlO__Xa0_adn7svsk Message-ID: Subject: Re: [PATCH v2 11/11] crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK To: Herbert Xu 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 26, 2018 at 2:20 AM, Herbert Xu wrote: > On Mon, Jun 25, 2018 at 02:10:26PM -0700, Kees Cook wrote: >> In the quest to remove all stack VLA usage from the kernel[1], this >> caps the skcipher request size similar to other limits and adds a >> sanity check at registration. In a manual review of the callers of >> crypto_skcipher_set_reqsize(), the largest was 384: >> >> 4 sun4i_cipher_req_ctx >> 6 safexcel_cipher_req >> 8 cryptd_skcipher_request_ctx >> 80 cipher_req_ctx >> 80 skcipher_request >> 96 crypto_rfc3686_req_ctx >> 104 nitrox_kcrypt_request >> 144 mv_cesa_skcipher_std_req >> 384 rctx >> >> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com >> >> Cc: Herbert Xu >> Cc: "David S. Miller" >> Cc: linux-crypto@vger.kernel.org >> Signed-off-by: Kees Cook > > This has the same issue as the ahash reqsize patch. Which are likely to be wrapped together? Should I take this to 512 or something else? -Kees -- Kees Cook Pixel Security