Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751184AbdFFEoL (ORCPT ); Tue, 6 Jun 2017 00:44:11 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:35009 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750736AbdFFEoJ (ORCPT ); Tue, 6 Jun 2017 00:44:09 -0400 Date: Mon, 5 Jun 2017 21:44:04 -0700 From: Eric Biggers To: "Jason A. Donenfeld" Cc: "Theodore Ts'o" , Linux Crypto Mailing List , LKML , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , David Miller , Herbert Xu Subject: Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using Message-ID: <20170606044404.GA3469@zzz> References: <20170606005108.5646-1-Jason@zx2c4.com> <20170606005108.5646-5-Jason@zx2c4.com> <20170606030004.4go6btmobrsmqiwz@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 29 On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote: > Hey Ted, > > On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote: > > Note that crypto_rng_reset() is called by big_key_init() in > > security/keys/big_key.c as a late_initcall(). So if we are on a > > system where the crng doesn't get initialized until during the system > > boot scripts, and big_key is compiled directly into the kernel, the > > boot could end up deadlocking. > > > > There may be other instances of where crypto_rng_reset() is called by > > an initcall, so big_key_init() may not be an exhaustive enumeration of > > potential problems. But this is an example of why the synchronous > > API, although definitely much more convenient, can end up being a trap > > for the unwary.... > > Thanks for pointing this out. I'll look more closely into it and see > if I can figure out a good way of approaching this. I don't think big_key even needs randomness at init time. The 'big_key_rng' could just be removed and big_key_gen_enckey() changed to call get_random_bytes(). (Or get_random_bytes_wait(), I guess; it's only reachable via the keyring syscalls.) It's going to take a while to go through all 217 users of get_random_bytes() like this, though... It's really a shame there's no way to guarantee good randomness at boot time. Eric