Received: by 10.192.165.156 with SMTP id m28csp531134imm; Tue, 17 Apr 2018 14:42:37 -0700 (PDT) X-Google-Smtp-Source: AIpwx49Hpl+CUs4gUlJSsFuwDaVC2JBXk3AV9vf1k8NBZG2k9nK2OFFdhV4y1v1yYBl0pPQ6BDpW X-Received: by 2002:a17:902:7007:: with SMTP id y7-v6mr3531830plk.227.1524001357054; Tue, 17 Apr 2018 14:42:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524001357; cv=none; d=google.com; s=arc-20160816; b=c9cIzmhGoOJGujTfTUgfI/IKEyk80ewB5qIUT1O44SL5L0YeEgvsXLR3VMHVj76lrA 2Cp4rYBJzgNGvu7MxhrlMDFimxE8O6DfScE3UISsfDRQFjQaDeZMKinic3O6+2aABQzC 0y6JernCAJEGI/LrUHtZ/LJ347jt+yn0c70gz+OEA+axEyv+yIzf9XquATEQfkCyLkJH TlsaVGHvIFAW9bXlSFq97HWBIHRfDbW3jzIwYGAphI5B2zQeS8IIKuXRL3UIqWQhtx9t fD8usr9iVDj0NBc15dcDfpKudvFzd7Yb6bpDk06/g41BoBujkrGGF6BlyI2r+TdnEnPM SO8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=pmGp+OHqa3cnGsLuDrO5f3+vejzSaXmxx8UxF5bqbE4=; b=dTHjAc7eA84ArvUbX/E+UKAsalDNKSz1Fn+mV9wb+gXpQJSDlVZMkeVt08R7ch0CSW 7PUcRQbhkYXpmunNt+Hnz6Z02BTzRcfqkmh/gF0i8tNhbUxwOAyzPqPRhyGq3UwNDVTv d7JdI6Qv7DAVm/Y+79ItLNI0uFH7bUFh5WJXQM9X4NF15xEldRmwsZVrhfcmctokIc2g dSkFelk9pRoq8uA8sGqScrPPrACPdsPwnOvELOCF6tYsxrdTEN+wWKKg0kJyzgmiH+ip kXUw97x6O0RXJDC52R8Lg0SvjwBofaZlq+/2SKOqyYON3cEAamTrjJZw/Im68KNsRn9b /cnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=FfCG4Rd0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o69si13901224pfi.322.2018.04.17.14.42.23; Tue, 17 Apr 2018 14:42:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=FfCG4Rd0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752985AbeDQVlF (ORCPT + 99 others); Tue, 17 Apr 2018 17:41:05 -0400 Received: from imap.thunk.org ([74.207.234.97]:53362 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751878AbeDQVlD (ORCPT ); Tue, 17 Apr 2018 17:41:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=pmGp+OHqa3cnGsLuDrO5f3+vejzSaXmxx8UxF5bqbE4=; b=FfCG4Rd0vcQU4psVbkdg+4X9Qv w4+Le0otBfZMaRbo9dn5V/Fuvs2fVmFAUYzm0u9dEOCJlfFT7Sr0wBnfNz4x7QJsnoK3r/X9q1dZI CbGvdxQXGHTJ9/VRt4KRUkx4i0XBQ5rGDkmvHiixeq9R90UW80tVHhU19pLvby3gnTdo=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1f8YLU-0005AD-FS; Tue, 17 Apr 2018 21:41:00 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id A28E97A4BD1; Tue, 17 Apr 2018 17:40:59 -0400 (EDT) Date: Tue, 17 Apr 2018 17:40:59 -0400 From: "Theodore Y. Ts'o" To: James Bottomley Cc: Matthew Wilcox , Alexey Dobriyan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: repeatable boot randomness inside KVM guest Message-ID: <20180417214059.GA23194@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , James Bottomley , Matthew Wilcox , Alexey Dobriyan , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20180414195921.GA10437@avx2> <20180414224419.GA21830@thunk.org> <20180415004134.GB15294@bombadil.infradead.org> <1523956414.3250.5.camel@HansenPartnership.com> <20180417114728.GA21954@bombadil.infradead.org> <1523966232.3250.15.camel@HansenPartnership.com> <20180417151650.GA16738@thunk.org> <1523979759.3310.7.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1523979759.3310.7.camel@HansenPartnership.com> User-Agent: Mutt/1.9.4 (2018-02-28) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 17, 2018 at 04:42:39PM +0100, James Bottomley wrote: > Depends how the parameter is passed. If it can be influenced from the > command line then a large class of "trusted boot" systems actually > don't verify the command line, so you can boot a trusted system and > still inject bogus command line parameters. This is definitely true of > PC class secure boot. Not saying it will always be so, just > illustrating why you don't necessarily want to expand the attack > surface. Sure, this is why I don't really like the scheme of relying on the command line. For one thing, the command-line is public, so if the attacker can read /proc/cmdline, they'll have access to the entropy. What I would prefer is an extension to the boot protocol so that some number of bytes would be passed to the kernel as a separate bag of bytes alongside the kernel command line and the initrd. The kernel would mix that into the random driver (which is written so the basic input pool and primary_crng can accept input in super-early boot). This woud be done *before* we relocate the kernel, so that kernel ASLR code can relocate the kernel test to a properly unpredictable number --- so this really is quite super-early boot. > OK, in the UEFI ideal world where every component is a perfectly > written OS, perhaps you're right. In the more real world, do you trust > the people who wrote the bootloader to understand and correctly > implement the cryptographically secure process of obtaining a random > input? In the default setup, I would expect the bootloader (such as grub) would read the random initialization data from disk. So it would work much like systemd reading from /var/lib/systemd/random-seed. And I would trust the bootloader implementors to be able to do this about as well as I would trust the systemd implementors. :-) It's not that hard, after all.... - Ted