Re: [RFC] Second attempt at kernel secure boot support

[Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>]

At Thu, 1 Nov 2012 13:18:49 +0000,
Alan Cox wrote:
> 
> > I think it make sense because the private key is still protected by
> > signer. Any hacker who modified firmware is still need use private key
> > to generate signature, but hacker's private key is impossible to match
> > with the public key that kernel used to verify firmware.
> > 
> > And, I afraid we have no choice that we need put the firmware signature
> > in a separate file. Contacting with those company's legal department
> > will be very time-consuming, and I am not sure all company will agree we
> > put the signature with firmware then distribute.
> 
> Then you'd better stop storing it on disk because your disk drive is FEC
> encoding it and adding a CRC 8)
> 
> It does want checking with a lawyer but my understanding is that if you
> have a file which is a package that contains the firmware and a signature
> then there is not generally a problem, any more than putting it in an RPM
> file - it's packaging/aggregation. This should be referred to the Linux
> Foundation folks perhaps - no point designing something badly to work
> around a non existant issue.
> 
> Also the interface needs to consider that a lot of device firmware is
> already signed. Nobody notices because they don't ever try and do their
> own thus many drivers don't need extra signatures in fact.

Besides the legal concern, embedding the signature into the firmware
makes the file incompatible with old kernel that has no support for
signed firmware.  That's the reason I put the files into a new
location in my test patch, /lib/firmware/signed/.  Having a separate
signature file would make this easier.

I cooked again quickly firmware loader code for the separate signature
files.  I'm going to send a series of test patches.


thanks,

Takashi