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

[Andy Lutomirski <luto@amacapital.net>]

On Tue, Jul 28, 2015 at 9:15 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2015-07-28 at 09:10 -0700, James Bottomley wrote:
>>
>> > Sure, but we shouldn't stick the USB vendor's key into the system
>> > keyring.  I'm fine with having it in the kernel or in some database,
>> > though.
>>
>> Actually, I don't think we should have a general system keyring for
>> firmware.  We need driver specific ones, so the USB vendor key is *only*
>> trusted for that particular driver.  Putting vendor keys into our
>> general keyring would be a recipe for inviting abuse.
>
> We need both.
>
> Where a firmware is signed by the vendor, the request_firmware() call
> itself can provide the hash of the acceptable signing cert. (And we'll
> want to handle the firmware we get with MS AuthentiCode signatures on
> them in a separate .cat file, as discussed.)
>
> In the case where firmware *doesn't* have a valid signature that comes
> all the way from the vendor, a signature that just says "this is what
> was in the linux-firmware.git tree" is better than nothing, and *that*
> cert can be in the system trusted keyring.
>

I'd really like to replace "the system trusted keyring" with
purpose-specific lists of keys.  There are keys we trust to sign
modules, there are keys we trust to sign kexec things, there will be
keys to trust to sign firmware for any device, etc.

Even now, I think we're conflating keys that we shouldn't conflate.
Arguably the keys for kexec and the keys for modules should be
different, because loading a module really gives you the right to do
anything, as does loading a kexec image without poking the TPM PCRs,
but I think we might want keys that can only sign kexec images that
are loaded after poking PCRs.  Crash kernels are in the latter
category.

--Andy