From patchwork Wed Apr 25 10:36:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tetsuo Handa X-Patchwork-Id: 10362783 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 11AC0601D3 for ; Wed, 25 Apr 2018 11:34:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0022628047 for ; Wed, 25 Apr 2018 11:34:12 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E6A6528F68; Wed, 25 Apr 2018 11:34:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 23E1428047 for ; Wed, 25 Apr 2018 11:34:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753142AbeDYKhD (ORCPT ); Wed, 25 Apr 2018 06:37:03 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:31720 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751561AbeDYKhA (ORCPT ); Wed, 25 Apr 2018 06:37:00 -0400 Received: from fsav403.sakura.ne.jp (fsav403.sakura.ne.jp [133.242.250.102]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w3PAaNlg052967; Wed, 25 Apr 2018 19:36:23 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav403.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav403.sakura.ne.jp); Wed, 25 Apr 2018 19:36:23 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav403.sakura.ne.jp) Received: from AQUA (softbank126099184120.bbtec.net [126.99.184.120]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w3PAaNXO052963; Wed, 25 Apr 2018 19:36:23 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) To: keescook@chromium.org, serge@hallyn.com Cc: tycho@tycho.ws, ebiggers3@gmail.com, dhowells@redhat.com, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, jmorris@namei.org, Jason@zx2c4.com Subject: Re: [PATCH 1/3] big key: get rid of stack array allocation From: Tetsuo Handa References: <20180424143539.GB3125@cisco> <201804242346.FHI69745.SQMHFVOOFLFOJt@I-love.SAKURA.ne.jp> <20180424145104.GC3125@cisco> <20180424195845.GB23575@mail.hallyn.com> In-Reply-To: Message-Id: <201804251936.GAG73463.HOJtFFOQSLFOVM@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Wed, 25 Apr 2018 19:36:21 +0900 Mime-Version: 1.0 Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Kees Cook wrote: > On Tue, Apr 24, 2018 at 12:58 PM, Serge E. Hallyn wrote: > > Quoting Tycho Andersen (tycho@tycho.ws): > >> On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote: > >> > Tycho Andersen wrote: > >> > > > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != GCM_AES_IV_SIZE)) { > >> > > > > + WARN(1, "big key algorithm changed?"); > >> > > >> > Please avoid using WARN() WARN_ON() etc. > >> > syzbot would catch it and panic() due to panic_on_warn == 1. > >> > >> But it is really a programming bug in this case (and it seems better > >> than BUG()...). Isn't this exactly the sort of case we want to catch? > >> > >> Tycho > > > > Right - is there a url to some discussion about this? Because not > > using WARN when WARN should be used, because it troubles a bot, seems > > the wrong solution. If this *is* what's been agreed upon, then > > what is the new recommended thing to do here? > > BUG() is basically supposed to never be used, as decreed by Linus. > WARN() here is entirely correct: if we encounter a case where > crypto_aead_ivsize(big_key_aead) != GCM_AES_IV_SIZE is not true, we > run the risk of stack memory corruption. If this is an EXPECTED > failure case, then okay, drop the WARN() but we have to keep the > -EINVAL. big_key_init() is __init function of built-in module which will be called only once upon boot, isn't it? Then, there is no point to continue after WARN(); BUG() is better here. Moreover, if this is meant for sanity check in case something went wrong (e.g. memory corruption), it is better to check at run time like --- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/security/keys/big_key.c b/security/keys/big_key.c index 9336237..bca04f2 100644 --- a/security/keys/big_key.c +++ b/security/keys/big_key.c @@ -22,6 +22,7 @@ #include #include #include +#include struct big_key_buf { unsigned int nr_pages; @@ -109,7 +110,12 @@ static int big_key_crypt(enum big_key_op op, struct big_key_buf *buf, size_t dat * an .update function, so there's no chance we'll wind up reusing the * key to encrypt updated data. Simply put: one key, one encryption. */ - u8 zero_nonce[crypto_aead_ivsize(big_key_aead)]; + u8 zero_nonce[GCM_AES_IV_SIZE]; + + if (crypto_aead_ivsize(big_key_aead) != sizeof(zero_nonce)) { + pr_err("big key algorithm changed?"); + return -EINVAL; + } aead_req = aead_request_alloc(big_key_aead, GFP_KERNEL); if (!aead_req) because crypto_aead_ivsize(big_key_aead) == GCM_AES_IV_SIZE is true unless something goes wrong at run time, isn't it? Moreover, zero_nonce[] can be "static" if all actions after memory allocation are guarded by global big_key_aead_lock mutex? diff --git a/security/keys/big_key.c b/security/keys/big_key.c index 9336237..1e7d2d1 100644 --- a/security/keys/big_key.c +++ b/security/keys/big_key.c @@ -22,6 +22,7 @@ #include #include #include +#include struct big_key_buf { unsigned int nr_pages; @@ -109,27 +110,28 @@ static int big_key_crypt(enum big_key_op op, struct big_key_buf *buf, size_t dat * an .update function, so there's no chance we'll wind up reusing the * key to encrypt updated data. Simply put: one key, one encryption. */ - u8 zero_nonce[crypto_aead_ivsize(big_key_aead)]; + static u8 zero_nonce[GCM_AES_IV_SIZE]; + + if (crypto_aead_ivsize(big_key_aead) != sizeof(zero_nonce)) { + pr_err("big key algorithm changed?"); + return -EINVAL; + } aead_req = aead_request_alloc(big_key_aead, GFP_KERNEL); if (!aead_req) return -ENOMEM; + mutex_lock(&big_key_aead_lock); memset(zero_nonce, 0, sizeof(zero_nonce)); aead_request_set_crypt(aead_req, buf->sg, buf->sg, datalen, zero_nonce); aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL); aead_request_set_ad(aead_req, 0); - - mutex_lock(&big_key_aead_lock); - if (crypto_aead_setkey(big_key_aead, key, ENC_KEY_SIZE)) { + if (crypto_aead_setkey(big_key_aead, key, ENC_KEY_SIZE)) ret = -EAGAIN; - goto error; - } - if (op == BIG_KEY_ENC) + else if (op == BIG_KEY_ENC) ret = crypto_aead_encrypt(aead_req); else ret = crypto_aead_decrypt(aead_req); -error: mutex_unlock(&big_key_aead_lock); aead_request_free(aead_req); return ret;