From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756587AbdKNUhy (ORCPT ); Tue, 14 Nov 2017 15:37:54 -0500 Received: from mail-it0-f46.google.com ([209.85.214.46]:40743 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755644AbdKNUhp (ORCPT ); Tue, 14 Nov 2017 15:37:45 -0500 X-Google-Smtp-Source: AGs4zMagl8talsLYSQjYlce6nOKIY1f+QtGyWNN8jb6ezMo1CeF92UMpOEUIsNGPHopgUbH+r3xp7OaG6mIipoNuQyo= MIME-Version: 1.0 In-Reply-To: References: <150842463163.7923.11081723749106843698.stgit@warthog.procyon.org.uk> <14219.1509660259@warthog.procyon.org.uk> <1509660641.3416.24.camel@linux.vnet.ibm.com> <20171107230700.GJ22894@wotan.suse.de> <20171108061551.GD7859@linaro.org> <20171108194626.GQ22894@wotan.suse.de> <20171109014841.GF7859@linaro.org> <1510193857.4484.95.camel@linux.vnet.ibm.com> <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> From: Matthew Garrett Date: Tue, 14 Nov 2017 15:37:43 -0500 Message-ID: Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown To: Linus Torvalds Cc: Mimi Zohar , David Howells , Alan Cox , "Luis R. Rodriguez" , "AKASHI, Takahiro" , Greg Kroah-Hartman , Jan Blunck , Julia Lawall , Marcus Meissner , Gary Lin , LSM List , linux-efi , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 14, 2017 at 3:35 PM, Linus Torvalds wrote: > On Tue, Nov 14, 2017 at 12:31 PM, Matthew Garrett wrote: >> >>> This is all theoretical security masturbation. The _real_ attacks have >>> been elsewhere. >> >> People made the same argument about Secure Boot, and then we >> discovered that people *were* attacking the boot chain. As we secure >> other components, the attackers move elsewhere. This is an attempt to >> block off an avenue of attack before it's abused. > > The thing is, if you have attested the system from boot, then you've > already attested the firmware before it even gets loaded. > > And if you haven't, then you can't trust anything else anyway. Sure you can. You don't need attestation to be able to assert that the system only booted signed code and that only you have control over that signing key.