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

[Josh Boyer <jwboyer@fedoraproject.org>]

On Tue, Jul 28, 2015 at 11:10 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
>> Patches are in the works for the provision of signatures for firmware blobs
>> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
>> firmware blobs get loaded where.
>>
>> Note that it has been agreed that signatures will be in separate files to the
>> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
>> that doesn't expect the signature.  Also, we don't want to modify the blob in
>> case of IP.
>>
>> We're currently using PKCS#7/CMS messages as the signature format since we
>> have a PKCS#7 parser and verifier already in the kernel for kexec.
>>
>> Patches have been proposed for inclusion in security/next that allow PKCS#11
>> to be used to supply h/w keys to the sign-file program and to the kernel build
>> process.
>>
>> There are a number of areas that could do with sorting out with regard key
>> policy:
>>
>>  (1) Should signatures produced by the manager of the linux-firmware package
>>      be allowed only?
>
> Firmware is a binary blob usually with no decompilation.  How would the
> package manager know its provenance?  The only people who know are the
> people who write the driver.  If they sign, I think we have to accept
> their signature and if not, we could have a weaker level of trust on the
> package manager based on unbroken chain of transmission from the
> firmware provider, but you'd have to trust the packaging organisation.

Packagers signing individual firmware files seems wrong.  As a
packager, I would want my signature to represent the fact that I
created this package and it is official in some capacity.  That
signature would naturally be on the package itself, e.g. an RPM
signature.

>>  (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.
>>
>>  (3) If the vendors of firmware blobs supply signatures, should we accept
>>      those instead of or as well as linux-firmware signatures?
>
> Of course, How are you going to validate other than by trusting the
> vendor?  Conversely, if you don't trust the vendor, why are you loading
> an unknown binary blob from them into a processing engine they made?
>
>>  (4) If we start taking vendor created blobs, what do we do with all the
>>      vendor keys?  Compiling them into the kernel could quickly get out of
>>      hand and asking the user to add them to the UEFI keystore has the
>>      potential to brick the user's system due to a dodgy BIOS.
>
> If the vendors buy in, I assume you'll eventually get them building them
> into their drivers.  In the interim, the package manager could supply
> the trusted keys at runtime.

Yes, adding them to the driver itself seems like the least painful
solution there.

josh