From patchwork Tue Jun 6 00:51:00 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: 9767785 X-Patchwork-Delegate: herbert@gondor.apana.org.au 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 D5E366034B for ; Tue, 6 Jun 2017 00:53:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CCDC427968 for ; Tue, 6 Jun 2017 00:53:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C196828435; Tue, 6 Jun 2017 00:53:48 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 72EDF27968 for ; Tue, 6 Jun 2017 00:53:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751388AbdFFAvs (ORCPT ); Mon, 5 Jun 2017 20:51:48 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:57707 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751194AbdFFAvq (ORCPT ); Mon, 5 Jun 2017 20:51:46 -0400 Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id e0f6bc17; Tue, 6 Jun 2017 00:51:25 +0000 (UTC) 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=A0mkZh3RpEUNxcRoULsqabpuqE0hLEE28CEp 1ukTkqOZDwTN6ThQiqPAGT2P20vdc7IwvQrnAIttzmkvtmV2r7fKr6wFEoCNz39o tbju40m4aCOfFKcB2Xgw7xxfxNbDjLg+AoC5jPSqrRUfTn1kVgHQa3965AgUvoNq hDBeaujXiy76ObQB16GaATt9tAQ6n0T5nqwYXicwi4MVSK9R/cNviX0YLyS35ZTI na1xcP+r+2R+mWejQq66NdvUKs/Sdcj0BWsSeo7GS6gMR7ULL3IuXiqfLORZ0oNa Vetg1bu5/zCGOQ3HZGQm+O3ZIr+hX8NdHKWY1HBobpBN4gnkTg== Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 2d5bd663 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Tue, 6 Jun 2017 00:51:24 +0000 (UTC) From: "Jason A. Donenfeld" To: Theodore Ts'o , Linux Crypto Mailing List , LKML , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , David Miller Cc: "Jason A. Donenfeld" , David Howells , Mimi Zohar , David Safford Subject: [PATCH v3 05/13] security/keys: ensure RNG is seeded before use Date: Tue, 6 Jun 2017 02:51:00 +0200 Message-Id: <20170606005108.5646-6-Jason@zx2c4.com> X-Mailer: git-send-email 2.13.0 In-Reply-To: <20170606005108.5646-1-Jason@zx2c4.com> References: <20170606005108.5646-1-Jason@zx2c4.com> Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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;