From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C6BC1409 for ; Tue, 28 Jul 2015 16:56:02 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4126E11B for ; Tue, 28 Jul 2015 16:56:02 +0000 (UTC) Received: by obbop1 with SMTP id op1so88819388obb.2 for ; Tue, 28 Jul 2015 09:56:01 -0700 (PDT) MIME-Version: 1.0 Sender: mcgrof@gmail.com In-Reply-To: <1438093418.26913.174.camel@infradead.org> References: <20436.1438090619@warthog.procyon.org.uk> <1438093418.26913.174.camel@infradead.org> From: "Luis R. Rodriguez" Date: Tue, 28 Jul 2015 09:55:41 -0700 Message-ID: To: David Woodhouse Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ksummit-discuss@lists.linuxfoundation.org, jkkm@jkkm.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Jul 28, 2015 at 7:23 AM, David Woodhouse wrot= e: >> (2) If the linux-firmware packages are signed by a single key (or just = a few >> keys) it may be manageable to compile all these keys into the kerne= l. > > I really think we want to allow firmware to be signed by the vendor who > created it =E2=80=94 and we want the linux-firmware.git repository to car= ry the > original vendors' signatures along with the firmware blobs. > > Having a signature generated by the linux-firmware packager which just > certifies that this *is* the blob that was in the linux-firmware.git > repository is only a partial solution. As we have it now the fist iteration of patches would just allow to trust a set a key signed by a trusted CA for the purpose firmware signing, and each firmware signature must be signed with a key intended for the purpose of firmware singing, additionally the signature would have the file name for the intended signature. Support for embedding a custom set of key attribute requirements is part of my second phase of firmware signing patches, to help replace CRDA with in-kernel functionality as that is one existing use case where what you say is what we needed. The second phase of patches would also allow drivers to make use of this though -- so what you say would be supported, but it would come in with the second set of patches. The reason it'd come in separately is the firmware API is already abused enough, we keep adding new routines with more arguments and I think that needs to end. The second set of patches introduce a new extensible API which lets users express the requirements for the "system data file" and then the core vets for its ability to meet the criteria passed and if it can find it, it hands it back. There's one caveat here, at least the way me and David envisioned system data extensions is that you'd have to register an OID into the kernel's registry and your key would have to be purposed for that OID. David mentions we don't have a limit to the OID registry but I don't think we were envisioning everyone having a custom set of requirements, although I cannot foresee any issues with this, other than the kernel size overhead. We did speak about dynamic extensions to this registry, so maybe that's the way to make it less of pain to the kernel's size. Perhaps the later should be something some vendors can opt-in to. That would provide for the flexibility to only those using those APIs (ie Intel), meanwhile if a distro disables firmware singing its all ignored, the next step would be if they enable firmware singing then the default trusted key (Kyle's) would be trusted. The system data API would enable subsystems and drivers to *require* a signature independent of what the distro said to firmware signing, ie, a different Kconfig entry. This would enable a silicon vendor to require signed firmware, and it'd work, so long as it was in linux-firmware, and the distro would not need firmware signing enabled. Luis