Messages in this thread | | | Date | Mon, 4 Jun 2012 09:38:43 -0400 | Subject | Re: [PATCH 00/23] Crypto keys and module signing | From | Josh Boyer <> |
| |
On Sun, Jun 3, 2012 at 9:16 PM, Rusty Russell <rusty@rustcorp.com.au> wrote: >> > 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.
Sure. RH could continue to maintain the original modsign patch too. I thought the point was to get the mechanism into the upstream kernel so that it was generally available though. Having the patches in the mainline kernel but not the strip tool seems somewhat unhelpful. I would think such a tool would be part of the Kbuild infrastructure.
> 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.
It's unfortunate, yes. The biggest case I can think of is splitting the debug symbols out of the modules after they are built (David might have other cases). Perhaps we could upstream that as well and organize it such that the modules are built, split for debuginfo, and then signed?
josh -- 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/
| |