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

[Andy Lutomirski <luto@amacapital.net>]

On Tue, Jul 28, 2015 at 8:31 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 08:22 -0700, Andy Lutomirski wrote:
>> On Tue, Jul 28, 2015 at 8: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.
>>
>> But IMO we really don't want trust $RANDOM_USB_WIDGET_VENDOR to supply
>> firmware for the GPU, for example.
>
> I'm not saying that.  I'm saying that if we verify some chain in
> firmware, it has to be from a trusted supplier to us, meaning we invest
> trust already in the supplier.  However, the trusted supplier should be
> the original device vendor.  if $RANDOM_USB_WIGET_VENDOR isn't the
> original vendor, then this would not trust them.  If they are, it's
> hobson's choice ... and god help us.

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.

--Andy