linux-kernel - Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Nov 2017 14:14:18 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Matthew Garrett <mjg59@...gle.com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Johannes Berg <johannes@...solutions.net>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        David Howells <dhowells@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Blunck <jblunck@...radead.org>,
        Julia Lawall <julia.lawall@...6.fr>,
        Marcus Meissner <meissner@...e.de>, Gary Lin <GLin@...e.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel
 lockdown

On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote:
> On Tue, Nov 14, 2017 at 3:50 PM, Luis R. Rodriguez <mcgrof@...nel.org
> > 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