[Ksummit-discuss] [TECH TOPIC] Firmware signing

Andy Lutomirski luto at amacapital.net
Tue Jul 28 17:05:45 UTC 2015


On Tue, Jul 28, 2015 at 9:42 AM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 17:18 +0100, David Howells wrote:
>> Andy Lutomirski <luto at amacapital.net> wrote:
>>
>> > Agreed.  See about.  I don't think the concept of trust should be as
>> > simple as "we trust" or "we don't trust" -- we should trust certain
>> > vendors for certain purposes only.
>>
>> How do you deal with a big vendor, like Intel, that makes lots of different
>> bits for lots of different purposes?
>
> I don't understand what you think the problem is?  What's not clear
> about "we have to trust the vendor".  If they choose to use a single key
> for multiple drivers, it's no more or less a problem than if they choose
> multiple keys, one for each driver.
>
> I think the trust we're investing is in the provenance of the blob, not
> the blob itself, so the firmware can't be substituted with a malicious
> version by an outside entity.  If we don't trust the firmware vendor,
> then all bets are off and the provenance chain is pretty meaningless.

I think we disagree on the scope of the trust.  I trust the USB widget
vendor to provide firmware for the USB widget.  I might as well trust
them to sign the firmware itself and to provide new signed blobs by
any means (web, email, shoved in a directory, whatever).  I have no
choice anyway, since they provided the device in the first place and
they could have burnt anything they wanted into it.

This does not mean that their key should be acceptable for kexec
images, modules, GPU firmware, firmware for different vendors' USB
sticks, firmware for my hard disk, etc.  In fact I flat out distrust
them if they ever try to provide such blobs.

--Andy


More information about the Ksummit-discuss mailing list