Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp634376imm; Thu, 6 Sep 2018 07:52:41 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZ6IocsdWm4LGklK2MQvzq+b8xc79S3uwsildP1fu1/jnyU60sGz9IGueZ2qWyuyCwp65Qd X-Received: by 2002:a17:902:6b05:: with SMTP id o5-v6mr3053918plk.338.1536245561730; Thu, 06 Sep 2018 07:52:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536245561; cv=none; d=google.com; s=arc-20160816; b=UajcnT+vlfaEJxaTHHN9mrzXf/Qs61/WZJEKYYPWgcgR8GWIhiC5yu5L/4uY5bGtPX pX9lkFcX+RjIQ/DjFxxveLQa1aey1mjlwZRBdMsPXyQqOsAeolvJOB7hKQpRdH/hPJXB JkbOy+oREdXBuHAkmJ25JLLPQrIwkDCS1zMwirLWdyEZV5Pb62fsXOJVSpTmWOKBTCiz XPSpp2HCc+zTQdgB08EpvHOW4ONpX7bLl86fLi+7RIIo78eEDUnWcMh6QBUSHdILRTd2 hd8T+8gHUXbnJKnWv8oRSNJAuoh68nyUFzol76DGkiVwp2nLMgLrxA7XlaIANNCqxu7R zDnA== 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; bh=dYHrLIXYEvwJh6k/dzs4C6FHlu/62s6QvnnmfaTNGec=; b=R1VuwO+YR4inVHNIiub43G3Z8PbDFgCpBadZkx8bIjPC4t9jpitQA76pCVzA2RD0N7 +TQjLCxIpQxoeR+jBOdKScanyRWh+n+lXVPm/3Ud2Lt2FdheTb37FKOSymQunIRnrohE bxZGwz/B1nNrbmodUAwFLzN8WK2+i4enY/9suJXTfdbyJTXCFiWL5mV07xAkTOtXlNKi Jt4AVOt8Bu0nw8AAtaPxxnzTpB+68wehbjNeb33TWl3FfxRzla7HaEZVc2n+D8M3nEsL WfVyU9bXNE/nEMkjjHxTremcSn3MiQ5CUIlTFvx4G0OY+H/CeuY9yzp1BtwS/n9LZu2l /dpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=F2IjubcU; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v3-v6si5001449plo.208.2018.09.06.07.52.24; Thu, 06 Sep 2018 07:52:41 -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=pass header.i=@linaro.org header.s=google header.b=F2IjubcU; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730246AbeIFTZU (ORCPT + 99 others); Thu, 6 Sep 2018 15:25:20 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:45015 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729840AbeIFTZU (ORCPT ); Thu, 6 Sep 2018 15:25:20 -0400 Received: by mail-io0-f195.google.com with SMTP id 75-v6so9019862iou.11 for ; Thu, 06 Sep 2018 07:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dYHrLIXYEvwJh6k/dzs4C6FHlu/62s6QvnnmfaTNGec=; b=F2IjubcUuNW3/SY/azM0ImDA0aSiEv4qpIh3ogQtvmObZL3BkkPFFTatjnlDgAlHDI LN4Ivt7y+WcEYdhrA/uTrmJa2pW7NRFlG1rNSnpXTX+J1YnJzhBQmahNedBc38hbS60x y16wYszPcPEt4hWYvo48O8UpMHG5AzyGRmre8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dYHrLIXYEvwJh6k/dzs4C6FHlu/62s6QvnnmfaTNGec=; b=Sd1rWrdHY+edBi31n36oajw8fEsMPFrRJtJUpxqgjkrWn7CUSpnf62Gz82iHSxPlQc NWqYG0DzDpZq2TLBdLBKj8xhPTWMcdEpPu+ru0dk0jBrh4MNaaNNrK+i9qqQ+NM6VOyw HR0jFkbzI068xcRFmEnKmH8fSQSMYJWLBMrqPovegc5tTGr/cU4ZYysFm+h3hXAzgbnX QczG2GsvzaLuRA9ZN9cNA3eoNXn9X7UKD+YsgqQCVOuVzcr4y+o6HWNDwVERWoWsEbkG y2+yqdUk80RBhxUHF6sMrucUuP8nGGtd0qKPQJre5To4E2rj3mSPLgJeVj4B8krdhrSJ /9bg== X-Gm-Message-State: APzg51B7lcDiQYw7FfHXvJVL4EJYNsoW5vMES0ZacoE0QyugasKxYWdD OxkWNr4qUHc3ouEEDUTPHtnmgFNk1vRHq28Rmiy2JA== X-Received: by 2002:a6b:ba86:: with SMTP id k128-v6mr2136154iof.170.1536245366680; Thu, 06 Sep 2018 07:49:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:1c06:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 07:49:25 -0700 (PDT) In-Reply-To: <20180906131149.ge2db74nxffs2tbz@gondor.apana.org.au> References: <20180904181629.20712-1-keescook@chromium.org> <20180904181629.20712-3-keescook@chromium.org> <20180906085100.xcqqftgqg4sizkec@gondor.apana.org.au> <20180906131149.ge2db74nxffs2tbz@gondor.apana.org.au> From: Ard Biesheuvel Date: Thu, 6 Sep 2018 16:49:25 +0200 Message-ID: Subject: Re: [PATCH 2/2] crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK To: Herbert Xu Cc: Gilad Ben-Yossef , Kees Cook , Eric Biggers , Antoine Tenart , Boris Brezillon , Arnaud Ebalard , Corentin Labbe , Maxime Ripard , Chen-Yu Tsai , Christian Lamparter , Philippe Ombredanne , Jonathan Cameron , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Linux Kernel Mailing List , linux-arm-kernel 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 6 September 2018 at 15:11, Herbert Xu wrote: > On Thu, Sep 06, 2018 at 11:29:41AM +0200, Ard Biesheuvel wrote: >> >> Perhaps not, but it is not enforced atm. >> >> In any case, limiting the reqsize is going to break things, so that >> needs to occur based on the sync/async nature of the algo. That also >> means we'll corrupt the stack if we ever end up using >> SKCIPHER_REQUEST_ON_STACK() with an async algo whose reqsize is >> greater than the sync reqsize limit, so I do think some additional >> sanity check is appropriate. > > I'd prefer compile-time based checks. Perhaps we can introduce > a wrapper around crypto_skcipher, say crypto_skcipher_sync which > could then be used by SKCIPHER_REQUEST_ON_STACK to ensure that > only sync algorithms can use this construct. > That would require lots of changes in the callers, including ones that already take care to use sync algos only. How about we do something like the below instead? diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h index 2f327f090c3e..ace707d59cd9 100644 --- a/include/crypto/skcipher.h +++ b/include/crypto/skcipher.h @@ -19,6 +19,7 @@ /** * struct skcipher_request - Symmetric key cipher request + * @__onstack: 1 if the request was allocated by SKCIPHER_REQUEST_ON_STACK * @cryptlen: Number of bytes to encrypt or decrypt * @iv: Initialisation Vector * @src: Source SG list @@ -27,6 +28,7 @@ * @__ctx: Start of private context data */ struct skcipher_request { + unsigned char __onstack; unsigned int cryptlen; u8 *iv; @@ -141,7 +143,7 @@ struct skcipher_alg { #define SKCIPHER_REQUEST_ON_STACK(name, tfm) \ char __##name##_desc[sizeof(struct skcipher_request) + \ - crypto_skcipher_reqsize(tfm)] CRYPTO_MINALIGN_ATTR; \ + crypto_skcipher_reqsize(tfm)] CRYPTO_MINALIGN_ATTR = { 1 }; \ struct skcipher_request *name = (void *)__##name##_desc /** @@ -437,6 +439,10 @@ static inline int crypto_skcipher_encrypt(struct skcipher_request *req) { struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req); + if (req->__onstack && + (crypto_skcipher_alg(tfm)->base.cra_flags & CRYPTO_ALG_ASYNC)) + return -EINVAL; + if (crypto_skcipher_get_flags(tfm) & CRYPTO_TFM_NEED_KEY) return -ENOKEY; @@ -458,6 +464,10 @@ static inline int crypto_skcipher_decrypt(struct skcipher_request *req) { struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req); + if (req->__onstack && + (crypto_skcipher_alg(tfm)->base.cra_flags & CRYPTO_ALG_ASYNC)) + return -EINVAL; + if (crypto_skcipher_get_flags(tfm) & CRYPTO_TFM_NEED_KEY) return -ENOKEY;