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]

Message-ID: <20171114205014.GJ729@wotan.suse.de>
Date:   Tue, 14 Nov 2017 21:50:14 +0100
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Johannes Berg <johannes@...solutions.net>
Cc:     Matthew Garrett <mjg59@...gle.com>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        David Howells <dhowells@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        "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, 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?

b) Other kernel components have implemented some sort of "signing" a file
   prior to sending it to the kernel. One is wifi for the regulatory.bin,
   through CRDA, and this helped us persuade certain folks to support wifi
   with open drivers. We can easily replace CRDA with kernel fetch for a
   signed file given most of the APIs for this is available.

Originally effort a) was done for b), as it was believed we needed a).
If we are saying a) is pointless, what about b)? A simple new
kernel_read_file_from_path_pkcs7_signed() or some such would suffice.

Johannes made cfg80211 recently just use request_firmware() now via commit on
linux-next 90a53e4432 ("cfg80211: implement regdb signature checking") [0] as
he got tired of waiting firmware signing, but note he implemented a signature
checking on its own so he open codes verify_pkcs7_signature() after the
request_firmware() call. If we are happy to live with this, then so be it.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=90a53e4432b12288316efaa5f308adafb8d304b0

  Luis