Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

["Luis R. Rodriguez" <mcgrof@do-not-panic.com>]

On Tue, Jul 28, 2015 at 7:23 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>>  (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 kernel.
>
> I really think we want to allow firmware to be signed by the vendor who
> created it — and we want the linux-firmware.git repository to carry 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