From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757274AbdKNWPI (ORCPT ); Tue, 14 Nov 2017 17:15:08 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:53830 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757144AbdKNWOW (ORCPT ); Tue, 14 Nov 2017 17:14:22 -0500 Message-ID: <1510697658.7703.12.camel@HansenPartnership.com> Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown From: James Bottomley To: Matthew Garrett , "Luis R. Rodriguez" Cc: 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:14:18 -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> 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 On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote: > On Tue, Nov 14, 2017 at 3:50 PM, Luis R. Rodriguez > wrote: > > > > On Tue, Nov 14, 2017 at 12:18:54PM -0800, Linus Torvalds wrote: > > > > > > This is all theoretical security masturbation. The _real_ attacks > > > have been elsewhere. > > > > In my research on this front I'll have to agree with this, in terms > > of justification and there are only *two* arguments which I've so  > > far have found to justify firmware signing: > > > > a) If you want signed modules, you therefore should want signed > > firmware. > >    This however seems to be solved by using trusted boot thing, > > given it > >    seems trusted boot requires having firmware be signed as well. > > (Docs > >    would be useful to get about where in the specs this is > > mandated, > >    anyone?). Are there platforms that don't have trusted boot or > > for which > >    they don't enforce hardware checking for signed firmware for > > which > >    we still want to support firmware signing for? Are there > > platforms > >    that require and use module signing but don't and won't have a > > trusted > >    boot of some sort? Do we care? > > 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. The question, really, in any system, is how you want to prove security.  In a standalone server system, measured boot is pretty useless because you don't have an external entity to attest to, so signatures and secure boot are really the bulwark against breaches.  In a properly attested server cluster whose attestation controller has the ability to reboot you, perhaps signatures and secure boot don't add that much more value. James