On Aug 12, 2016 3:30 PM, "Vinod Koul" <vinod.koul@intel.com> wrote:
>
> On Wed, Aug 03, 2016 at 11:47:26AM +0200, Linus Walleij wrote:
> > On Tue, Aug 2, 2016 at 4:13 PM, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > On Tue, 2016-08-02 at 14:54 +0200, Linus Walleij wrote:
> >
> > >> What I always intuitively felt is that I would be happy if the same
> > >> GPG keys we use for pull requests of kernel code would extend
> > >> to firmware signing, so that we move from the overall-industry
> > >> focus on legislative bodies (Thawte, ...) signing certificates with
> > >> OpenSSL and thus being the root of trust, over to putting the root
> > >> of trust for any software related to Linux into the same web of
> > >> trust that we already use for developing the code per se.
> > >
> > > This is the vision that Monkeysphere is based on
> > >
> > > http://web.monkeysphere.info/
> >
> > That looks nice.
> >
> > >> I would certainly trust a firmware signed by say Laurent Pinchart,
> > >> but not sure about one signed by E.Corp.
> > >
> > > Really?  Assuming E.Corp is the one actually producing the firmware,
> > > why would you say they're less qualified than Laurent to certify their
> > > own firmware.  Half the SCSI chips I see have proprietary firmware.
> > >  Even if I were willing to sign it, would you really trust my
signature
> > > when I can't even decompile it?
> >
> > I would trust an Intel WiFi driver if it was signed by Dirk Hohndel
> > or H. Peter Anvin whose GPG keys I have in my own web of trust
> > and work for Intel. And this is simply because I trust these guys
> > more than the corporate entity they work for.
>
> One more point worth mentioning here...
>
> Whatever solution we decide, some firmware is already signed. Some of
> the Intel firmware we submit to linux-firmware is signed and a firmware
> with bad or unsigned keys will fail to load on these devices. Now how
> much we are willing to trust that is entirely different question.
>
> Any solution needs to comprehend that additional signing might be
> present.

I see device-verified signatures as orthogonal: the kernel loads a blob,
optionally verifies the blob, and that blob just happens to contain a
signature.

--Andy