From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756517AbdKNWbr (ORCPT ); Tue, 14 Nov 2017 17:31:47 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:54094 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752787AbdKNWbj (ORCPT ); Tue, 14 Nov 2017 17:31:39 -0500 Message-ID: <1510698696.7703.21.camel@HansenPartnership.com> Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown From: James Bottomley To: Matthew Garrett Cc: "Luis R. Rodriguez" , Linus Torvalds , Johannes Berg , Mimi Zohar , David Howells , Alan Cox , "AKASHI, Takahiro" , Greg Kroah-Hartman , Jan Blunck , Julia Lawall , Marcus Meissner , Gary Lin , LSM List , linux-efi , Linux Kernel Mailing List Date: Tue, 14 Nov 2017 14:31:36 -0800 In-Reply-To: References: <20171109044619.GG7859@linaro.org> <20171111023240.2398ca55@alans-desktop> <20171113174250.GA22894@wotan.suse.de> <20171113210848.4dc344bd@alans-desktop> <454.1510609487@warthog.procyon.org.uk> <1510662098.3711.139.camel@linux.vnet.ibm.com> <20171114205014.GJ729@wotan.suse.de> <1510697658.7703.12.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Archived-At: List-Archive: List-Post: On Tue, 2017-11-14 at 14:17 -0800, Matthew Garrett wrote: > On Tue, Nov 14, 2017 at 2:14 PM, James Bottomley > wrote: > > > > On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote: > > > > > > TPM-backed Trusted Boot means you don't /need/ to sign anything, > > > since the measurements of what you loaded will end up in the TPM. > > > But signatures make it a lot easier, since you can just assert > > > that only signed material will be loaded and so you only need to > > > measure the kernel and the trusted keys. > > > > Actually, I'd disagree with that quite a lot: measured boot only > > works if you're attesting to something outside of your system that > > has the capability for doing something about a wrong > > measurement.  Absent that, measured boot has no safety > > whatsoever.  Secure boot, on the other hand, can enforce not > > booting with elements that fail the signature check. > > Measured boot has a great deal of value in the sealing of private > material, even in the absence of attestation. The way Microsoft make > use of PCR7 is a good example of how signatures make this easier - > achieving the same goal with a full measurement of the boot chain > instead of relying on signature validation results in significantly > more fragility. OK, so I agree that if you have sealed something required for boot (and have the capability for resealing it on OS upgrade) you can use measurements locally.  However, I don't believe we have any systems today in Linux which can do this (we have theoretical ideas about how we might do it with LUKS root keys and one day we might actually have the infrastructure to make it viable for a standard laptop). Absent that, secure boot provides a reasonable measure of security which works with today's infrastructure. Note: this doesn't mean I necessarily want signatures everywhere (like firmware).  We can sign elements in blobs that provide the effective security without needing more granular signatures. James