[lkml]   [2012]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 00/23] Crypto keys and module signing
On Sun, May 27, 2012 at 03:11:23PM +0930, Rusty Russell wrote:
> > > > Why would you want multiple signatures? That just complicates things.
> > >
> > > The code above stays pretty simple; if the signature fails, you set size
> > > to i, and loop again. As I said, if you know exactly how you're going
> > > to strip the modules, you can avoid storing the stripped module and
> > > simply append both signatures.
> >
> > You still haven't justified it. One of your arguments about rejecting the ELF
> > parsing version was that it was too big for no useful extra value that I could
> > justify. Supporting multiple signatures adds extra size and complexity for no
> > obvious value.
> One loop is a lot easier to justify that the ELF-parsing mess. And it
> can be done in a backwards compatible way tomorrow: old kernels will
> only check the last signature.
> I had assumed you'd rather maintain a stable strip util which you can
> use on kernel modules than rework your module builds. I guess not.

To dig an old thread up, but what really is wrong with the original ELF
section stuff? Why encode "magic" values on the end of the kernel
module that then require all userspace tools to be modified in order to
properly handle this?

When I first did this so many many years ago an elf section made it so
easy to handle. Userspace didn't need to be modified, and everyone
knows how to handle elf sections, even the kernel does :)

And I think we really want the ability to have multiple signatures, the
whole "chain of trust" thing that is needed will work out much better if
multiple signatures are allowed. Putting it in an elf section allows
this to work out easier, right?


greg k-h

 \ /
  Last update: 2012-06-22 04:41    [W:0.196 / U:10.680 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site