Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862AbdFGRig (ORCPT ); Wed, 7 Jun 2017 13:38:36 -0400 Received: from foss.arm.com ([217.140.101.70]:36092 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751768AbdFGRif (ORCPT ); Wed, 7 Jun 2017 13:38:35 -0400 Date: Wed, 7 Jun 2017 18:37:50 +0100 From: Mark Rutland To: "Theodore Ts'o" , "Jason A. Donenfeld" , Eric Biggers , Linux Crypto Mailing List , LKML , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , David Miller , Herbert Xu , Stephan Mueller , Ard Biesheuvel Subject: Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using Message-ID: <20170607173749.GC8330@leverpostej> References: <20170606005108.5646-1-Jason@zx2c4.com> <20170606005108.5646-5-Jason@zx2c4.com> <20170606030004.4go6btmobrsmqiwz@thunk.org> <20170606044404.GA3469@zzz> <20170606170319.5eva2yoxxeru5p74@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170606170319.5eva2yoxxeru5p74@thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1428 Lines: 31 On Tue, Jun 06, 2017 at 01:03:19PM -0400, Theodore Ts'o wrote: > The other approach is to find a way to have initialized "seed" entropy > which we can count on at every boot. The problem is that this is very > much dependent on how the bootloader works. It's easy to say "store > it in the kernel", but where the kernel is stored varies greatly from > architecture to architecture. In some cases, the kernel can stored in > ROM, where it can't be modified at all. > > It might be possible, for example, to store a cryptographic key in a > UEFI boot-services variable, where the key becomes inaccessible after > the boot-time services terminate. But you also need either a reliable > time-of-day clock, or a reliable counter which is incremented each > time the system that boots, and which can't be messed with by an > attacker, or trivially reset by a clueless user/sysadmin. FWIW, EFI has an (optional) EFI_RNG_PROTOCOL, that we currently use to seed the kernel's entropy pool. The EFI stub creates a config table with the entropy, which the kernel reads. This is re-seeded prior to kexec() to avoid the entropy being recycled. See commits: 636259880a7e7d34 ("efi: Add support for seeding the RNG from a UEFI config table") 568bc4e87033d232 (" efi/arm*/libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") Unfortunately, I beleive that support for the protocol is currently rare in practice. Thanks, Mark.