Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH 00/23] Crypto keys and module signing | Date | Mon, 04 Jun 2012 10:46:01 +0930 |
| |
On Thu, 31 May 2012 11:35:23 -0400, Josh Boyer <jwboyer@gmail.com> wrote: > On Sun, May 27, 2012 at 1:41 AM, Rusty Russell <rusty@rustcorp.com.au> wrote: > > On Thu, 24 May 2012 15:00:51 +0100, David Howells <dhowells@redhat.com> 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. > > Could you elaborate on this part a bit? Do you mean integrate a > standalone strip utility in the kernel sources and maintain that for > use during module builds? Or am I misunderstanding and you meant > something else?
In the kernel sources, no. But could RH maintain such a thing? Surely.
Whether they want to guarantee that their strip is stable on kernel modules, or create a minimal 'kmod-strip' is up to them.
> I can see how that sounds simple and desirable from one aspect, but > it seems somewhat odd to me to duplicate the existing (or create from > scratch) strip utilities.
Mangling a module after it is signed is very odd, and odd things aren't nice for security features. That's how we got here; I'm trying to move the oddness out of the verification path.
Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |