From patchwork Tue Jun 6 17:47:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 9769375 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 2FA116035D for ; Tue, 6 Jun 2017 17:48:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2BC35284DA for ; Tue, 6 Jun 2017 17:48:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 20C95284E4; Tue, 6 Jun 2017 17:48:52 +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=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 31958284DA for ; Tue, 6 Jun 2017 17:48:50 +0000 (UTC) Received: (qmail 1542 invoked by uid 550); 6 Jun 2017 17:48:27 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 32727 invoked from network); 6 Jun 2017 17:48:25 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=from:to:cc :subject:date:message-id:in-reply-to:references; s=mail; bh=CEl3 SZwHmEChf0jQgaJFq+nROLQ=; b=tQ+ye8mCo7glt8ZPSMYY+MblKZETUWSuSQKy hBwQCyvL/CdiK5ZHYtetntEt6mqLbl/IZzM0QdI7aj3RiOi9Bv6XWRwIL7/t8Sq4 MMehLd2iu2OvNuKLdbn1dj9WDegjSVKprylSsbQ6W4V0Wy09EgEWWsS4jwaH9MJt tL4c7urhX325idaQCkLICNlfyqDWAEvVjWAVudJqXx6wBECaNqoFo0qtAeZVouZM nHeF5u+3Wk0/SaJG6XetriQnls6EgCgKokGLlijCVJqrxeiZ0mAU275J4R9FlcOZ p7kOnkmQRnd/ptIjVRYrioK4g0ZvJsjRLcwn40P8lBayxwxrRw== From: "Jason A. Donenfeld" To: Theodore Ts'o , Linux Crypto Mailing List , LKML , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , David Miller , Eric Biggers Cc: "Jason A. Donenfeld" , David Howells , Mimi Zohar , David Safford Date: Tue, 6 Jun 2017 19:47:55 +0200 Message-Id: <20170606174804.31124-5-Jason@zx2c4.com> X-Mailer: git-send-email 2.13.0 In-Reply-To: <20170606174804.31124-1-Jason@zx2c4.com> References: <20170606174804.31124-1-Jason@zx2c4.com> Subject: [kernel-hardening] [PATCH v4 04/13] security/keys: ensure RNG is seeded before use X-Virus-Scanned: ClamAV using ClamSMTP Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). However, we can't change to using a blocking function in key serial allocation, because this will block booting in some configurations, so here we use the more appropriate get_random_u32, which will use RDRAND if available. Signed-off-by: Jason A. Donenfeld Cc: David Howells Cc: Mimi Zohar Cc: David Safford --- security/keys/encrypted-keys/encrypted.c | 8 +++++--- security/keys/key.c | 16 ++++++++-------- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c index 0010955d7876..d51a28fc5cd5 100644 --- a/security/keys/encrypted-keys/encrypted.c +++ b/security/keys/encrypted-keys/encrypted.c @@ -777,10 +777,12 @@ static int encrypted_init(struct encrypted_key_payload *epayload, __ekey_init(epayload, format, master_desc, datalen); if (!hex_encoded_iv) { - get_random_bytes(epayload->iv, ivsize); + ret = get_random_bytes_wait(epayload->iv, ivsize); + if (unlikely(ret)) + return ret; - get_random_bytes(epayload->decrypted_data, - epayload->decrypted_datalen); + ret = get_random_bytes_wait(epayload->decrypted_data, + epayload->decrypted_datalen); } else ret = encrypted_key_decrypt(epayload, format, hex_encoded_iv); return ret; diff --git a/security/keys/key.c b/security/keys/key.c index 455c04d80bbb..b72078e532f2 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -134,17 +134,15 @@ void key_user_put(struct key_user *user) * Allocate a serial number for a key. These are assigned randomly to avoid * security issues through covert channel problems. */ -static inline void key_alloc_serial(struct key *key) +static inline int key_alloc_serial(struct key *key) { struct rb_node *parent, **p; struct key *xkey; - /* propose a random serial number and look for a hole for it in the - * serial number tree */ + /* propose a non-negative random serial number and look for a hole for + * it in the serial number tree */ do { - get_random_bytes(&key->serial, sizeof(key->serial)); - - key->serial >>= 1; /* negative numbers are not permitted */ + key->serial = get_random_u32() >> 1; } while (key->serial < 3); spin_lock(&key_serial_lock); @@ -170,7 +168,7 @@ static inline void key_alloc_serial(struct key *key) rb_insert_color(&key->serial_node, &key_serial_tree); spin_unlock(&key_serial_lock); - return; + return 0; /* we found a key with the proposed serial number - walk the tree from * that point looking for the next unused serial number */ @@ -314,7 +312,9 @@ struct key *key_alloc(struct key_type *type, const char *desc, /* publish the key by giving it a serial number */ atomic_inc(&user->nkeys); - key_alloc_serial(key); + ret = key_alloc_serial(key); + if (ret < 0) + goto security_error; error: return key;