Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754123AbbDRRC2 (ORCPT ); Sat, 18 Apr 2015 13:02:28 -0400 Received: from imap.thunk.org ([74.207.234.97]:46198 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752358AbbDRRC0 (ORCPT ); Sat, 18 Apr 2015 13:02:26 -0400 Date: Sat, 18 Apr 2015 13:02:19 -0400 From: "Theodore Ts'o" To: Sandy Harris Cc: LKML , greg@kroah.com, John Denker Subject: Re: Read/write file from random(4) driver Message-ID: <20150418170219.GA25265@thunk.org> Mail-Followup-To: Theodore Ts'o , Sandy Harris , LKML , greg@kroah.com, John Denker References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4208 Lines: 77 On Sat, Apr 18, 2015 at 11:28:16AM -0400, Sandy Harris wrote: > What I'd like to add is a small (128 to 512 bits) file that the driver > tries to read during initialisation and writes periodically later. > This would not completely solve the problem but by moving the > read/write into the kernel it avoids the risk that vendors bungling > the scripts will break the driver. Where would this file live? The place where this is an issue is with embedded devices, which is where we're most likely to see incompetent product engineers who don't deal with initializing entropy pool. The problem is that on those embedded platforms, it's much more likely that the file system layout is going to be non-stadard, or where the root file system is mounted read-only. Worse, if the kernel tries to do this in an uncoordinated way, it could end up writing the file while the root file system is part of the initial ram disk, so the state won't get saved. (Or part of an overlayfs composed of a tmpfs on top of a read-only file system, etc.) > This looks secure in all cases except first boot or an enemy who gets > root and reads the putatively secret data. Use a variant of Denker's > proposal to create a unique initial version of the file for each > install and it handles first boot as well. ... except the first boot problem is actually the harder problem, and generally, the more critical one, since so many userspace applications generate permanent long-term public keys within hudreds of milliseconds of the first boot. In addition, Denker's proposal assumes a competently implemented userspace --- while your proposal assumes incompetent product engineers. I don't believe we can solve the problem in the kernel, because as the saying goes, "fools are so ingenious". We can't make random pool initialization foolproof. On laptops and desktops, this problem is already effectively solved, since in practice, the entropy pool is initialized before the root file system is remounted read/write, at least if you use sysvinit. Unfortunately, this is not always true if you use systemd, because it's __too__ fast --- and because systemd reads from /dev/urandom very early in the boot cycle, well before the root file system is mounted and before the entropy pool has a chance to be initialized. Grep for "random" the following line in dmesg shortly after the system is booted, and weep: Apr 16 13:24:01 closure kernel: [ 1.135749] random: systemd-udevd urandom read with 19 bits of entropy available Apr 16 13:24:01 closure kernel: [ 3.329190] random: nonblocking pool is initialized Fortunately, I don't *think* systemd is doing anything cryptographically sensitive yet, but that's only because it hasn't subsumed openssh yet. :-) And hopefully, with the exception of openssh generating host ssh keys the first time the system is booted, in most cases by the time most user-initiated security sensitive applications are started, the entropy pool will be initialized. Getting back to the point, I firmly believe the right answer is to try to fix systemd, Intel's Yacto distribution, etc, to do the right thing. Keep in mind that even if we fix in the kernel right now, thanks to out-of-tree device driver, I am aware of brand-new products that are just getting started in the design phase a few months ago, which are using a 3.2 kernel. (This is an improvement, BTW, the previous version of that particuarly product was using 2.6.32. The engineers wanted to use a newer kernel, but they were constrained by device driver availability.) So if we can fix userspace, it's more likely that these crappy embedded products will more likely be secure. (Assuming you can get the embedded developers to use the latest version of the userspace distributions / frameworks, granted, which is not at all guaranteed, but they are more likely to use newer userspace than they are the latest kernels, due to the device driver issue.) Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/