Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp22157imm; Tue, 17 Jul 2018 13:09:42 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcZ0Ttxa6l9RET25SABFfnB7E3W8hFsHJHvZ1xmVJSo7EgGjkhghWGGAHT+6sSRXkIbcDC+ X-Received: by 2002:aa7:88d3:: with SMTP id p19-v6mr2132673pfo.160.1531858182225; Tue, 17 Jul 2018 13:09:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531858182; cv=none; d=google.com; s=arc-20160816; b=crd6A8llDqeHoZOpxuJVJkewDwox2CNxPskEyYP3iGmd6IG9aylmMPKp7fNmr49426 /P770RNV3JEe1m17H3orixjuOkL2302owC5Zzwc1rHoSHalSkgjUN7uhOLshhJY2oo3y RpkZ+x7FtSpEQcW4VD1RKVh3kkZB/qF/i4wGr3BKoLw73F/Ew2udjgGuy7YaRMHrUzTg bwBrCNg/+oDEBmqTK2K1qLVB/Z/B/obcDfvdSa9VXlxiQk5uQhEwYTm/YNv1Hd57c9kZ H/xUk9kC4LbyBle/FWdGqbEBFIoeKbfxf4NATTLKaYLgcyunOnGo1LOB5i+/Hrf/eT/S oUHQ== 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=X6lBtrCenNy5Dza3t5CsfoNuyhb8zfp/3gAtHtGNTdg=; b=wbqCSp3gLjOQ+1az3Pu6VQi/7mWjFeNO/W8Qq5f+HOxVvuVFA9ZF1yVGzKteFQQVrO WPJBxkJFKCA7XdR03CvwbYPwUiI4m3S4ht4oEP6XuJwP9VdDEgdk5oiJdJu7Jb7iulEM 8kdV62sha0sFI576AjOuuTN/D4cINvu29gTuP5kRrolZ8yc44yMvKDwGNQysDM2JZVfX k+ztxRUAFFzLggSvc1xGq103KTf6Sg3XrJbkkBsMbz+kDaLm4yPv4t56X45ON9huR+5/ IwCRrRA+/XhcM9sGMApiWP+UFkpqOKZthGdZ705/LgsrLUJIYvdKIZ2eFkBIu80+vPZR dcaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=nEuJUL5P; dkim=fail header.i=@chromium.org header.s=google header.b=N+ONVPxR; 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 h89-v6si1580593pld.378.2018.07.17.13.09.12; Tue, 17 Jul 2018 13:09:42 -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=nEuJUL5P; dkim=fail header.i=@chromium.org header.s=google header.b=N+ONVPxR; 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 S1730735AbeGQUmF (ORCPT + 99 others); Tue, 17 Jul 2018 16:42:05 -0400 Received: from mail-yw0-f193.google.com ([209.85.161.193]:44783 "EHLO mail-yw0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729855AbeGQUmF (ORCPT ); Tue, 17 Jul 2018 16:42:05 -0400 Received: by mail-yw0-f193.google.com with SMTP id k18-v6so856127ywm.11 for ; Tue, 17 Jul 2018 13:07:51 -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=X6lBtrCenNy5Dza3t5CsfoNuyhb8zfp/3gAtHtGNTdg=; b=nEuJUL5PnA7FE3/SJ/EStfcNrdnqj8tibArIiL7pXa2AIStwrqqJLAHLkwoyOjB4cC x7395gyM0CxrLxc97YAqYbOAzcAPJeAoc98ZEta1mP0Jhy1vkBrZaXVhoGUSxOsOL6yv ory6DB3OSMqp+qM2SzGy7elcCMBYvAD0B1SrQ5H5+d8uX4Eb0lOO731tTS4gIK6ccCMo M6L6VcIgkFeaPyLTbjmEXszRVl2iccBI78zROBGKZ+G5oL6LBj5j7JjfhmsreXFWwqxU jpHvDdYoYC8z7YLGk4sroFHLFe5DKizv/pzISkzwtis4j23KpObIK5A0WBhrVvPpPBNj tk3A== 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=X6lBtrCenNy5Dza3t5CsfoNuyhb8zfp/3gAtHtGNTdg=; b=N+ONVPxRbJHbuAtz5TgQ/IkDDRkwiN33SDm+/s+UHDufl4sAaniZphQ/JtAcnRueJp Xqh1AHL722WhHAyuuY2u9/0zOtriZZ5OFEDfL6TpG9OifmgmeYgQibYeYuutkOXiRgQR gRvqe2RRBDpUQI7jU8EybtjzCGD3XRyCX7fVo= 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=X6lBtrCenNy5Dza3t5CsfoNuyhb8zfp/3gAtHtGNTdg=; b=VMl+JvnHqlOk5Gp7PI9VfHpdAHaEDv5up0BK0ijV+ABHfbSrUwNtM0DUFvkHewr9tc imNKXUsxKnSV+CtJHUm/7QdtiI3eATQzJnEpQe+JER3a9Yr5wRIQiT/I/pMOpN+0+FX2 fpWwlJbeRAGCI2TG6S2FwpzmHGSCMMqnRBdxn5mhTDcxipdR5WL1fLrw5mFBLSQ1v2Ih B460v06mxPsq5KFNa1To1BQAhipqTcKBO5pttU1NlL14sDl5IkwX4UQEYgM5wDmV1K6A x7aI/QWnJV4VjW4plVy/0kdjqFabMuXG7dIKwCvkTXR/Rqi7W2SylJ5ag4vRxLUF+wMi rDTw== X-Gm-Message-State: AOUpUlFmz4WD7To9x1ZFCnk1J6vEAmISKFLD+rzgkdvmfVjUWy0/YXai iW3I4C+ilUHmEb+uy1d3AYC47qw6TJYQEkkOWZRgMQ== X-Received: by 2002:a81:2706:: with SMTP id n6-v6mr1596783ywn.88.1531858070714; Tue, 17 Jul 2018 13:07:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:6602:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 13:07:50 -0700 (PDT) In-Reply-To: <20180717163936.GB75957@gmail.com> References: <20180717042150.37761-1-keescook@chromium.org> <20180717042150.37761-6-keescook@chromium.org> <20180717163936.GB75957@gmail.com> From: Kees Cook Date: Tue, 17 Jul 2018 13:07:50 -0700 X-Google-Sender-Auth: VJdsoLPqumtapTCOIENYSKGJN84 Message-ID: Subject: Re: [dm-devel] [PATCH v5 05/11] crypto: ahash: Remove VLA usage To: Eric Biggers Cc: Herbert Xu , Giovanni Cabiddu , Arnd Bergmann , "Gustavo A. R. Silva" , Mike Snitzer , Eric Biggers , qat-linux@intel.com, LKML , dm-devel@redhat.com, linux-crypto , Lars Persson , Tim Chen , Alasdair Kergon , Rabin Vincent 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, Jul 17, 2018 at 9:39 AM, Eric Biggers wrote: > On Mon, Jul 16, 2018 at 09:21:44PM -0700, Kees Cook wrote: >> In the quest to remove all stack VLA usage from the kernel[1], this >> introduces max size macros for ahash, as already done for shash, and >> adjust the crypto user to max state size. >> >> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com >> >> Signed-off-by: Kees Cook >> --- >> crypto/ahash.c | 4 ++-- >> crypto/algif_hash.c | 2 +- >> include/crypto/hash.h | 3 +++ >> 3 files changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/crypto/ahash.c b/crypto/ahash.c >> index a64c143165b1..6435bdbe42fd 100644 >> --- a/crypto/ahash.c >> +++ b/crypto/ahash.c >> @@ -550,8 +550,8 @@ static int ahash_prepare_alg(struct ahash_alg *alg) >> { >> struct crypto_alg *base = &alg->halg.base; >> >> - if (alg->halg.digestsize > PAGE_SIZE / 8 || >> - alg->halg.statesize > PAGE_SIZE / 8 || >> + if (alg->halg.digestsize > AHASH_MAX_DIGESTSIZE || >> + alg->halg.statesize > AHASH_MAX_STATESIZE || >> alg->halg.statesize == 0) >> return -EINVAL; >> >> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c >> index bfcf595fd8f9..8974ee8ebead 100644 >> --- a/crypto/algif_hash.c >> +++ b/crypto/algif_hash.c >> @@ -239,7 +239,7 @@ static int hash_accept(struct socket *sock, struct socket *newsock, int flags, >> struct alg_sock *ask = alg_sk(sk); >> struct hash_ctx *ctx = ask->private; >> struct ahash_request *req = &ctx->req; >> - char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req)) ? : 1]; >> + char state[AHASH_MAX_STATESIZE]; >> struct sock *sk2; >> struct alg_sock *ask2; >> struct hash_ctx *ctx2; >> diff --git a/include/crypto/hash.h b/include/crypto/hash.h >> index ae14cc0e0cdb..4fcd0e2368cd 100644 >> --- a/include/crypto/hash.h >> +++ b/include/crypto/hash.h >> @@ -64,6 +64,9 @@ struct ahash_request { >> void *__ctx[] CRYPTO_MINALIGN_ATTR; >> }; >> >> +#define AHASH_MAX_DIGESTSIZE 512 >> +#define AHASH_MAX_STATESIZE 512 >> + > > Why is AHASH_MAX_DIGESTSIZE (512) so much larger than SHASH_MAX_DIGESTSIZE (64)? > I would have expected them to be the same. This was a direct replacement of the PAGE_SIZE / 8 original limit. This this didn't trip any frame size warnings, it seemed like we didn't need to do the more narrow limitations done elsewhere. I am, of course, happy to do a manual review and find a lower alternative if that's desired. -Kees -- Kees Cook Pixel Security