Re: Fw: signed kernel modules?

[Rusty Russell]

On Thu, 2004-10-14 at 21:02, David Howells wrote:
> > I'd prefer to see:
> > 	err = module_verify(hdr, len, &gpgsig_ok);
> > 	if (err)
> > 		goto free_hdr;
> 
> I've been moaned at for doing this before. Other people have told me they
> prefer to see the value returned through the return value since there's enough
> scope.

I suppose this is a matter of taste.  I find it much clearer this way,
to overloading 0 vs 1 returns.

> > And then have module_verify for the !CONFIG_MODULE_SIG case (in
> > module-verify.h) simply be:
> 
> I think it should still check the ELF, even if we're not going to check a
> signature. This permits us to drop a few checks later in the module loading
> process.

Not really: I've never had a single bug report, and I've had a fair
number of bug reports.  Without signed modules, it's really 300 lines of
code for no actual gain.  OTOH, it's going to be in the tree anyway. 
Unless we want to "sign" modules with a straight checksum when
!CONFIG_MODULE_SIG?  I'm not really convinced it's worth it.  Thoughts
welcome.

> > Multiplicative overflow.
> 
> Not so in this ELF incarnation.

Sorry, my bad.

Now we have the code in front of us, I'll ask you to answer honestly. 
Do *you* think that the extra ~600 lines of code is a worthwhile
tradeoff so we can simply strip modules without resigning?  You know my
opinion, but you've done the code, and if you're really convinced of
that, I'll ack it.

(I'm not sure that having a whole GPG format parser in the kernel
matches our minimalistic ideals either, but I can see a much stronger
incentive there: less risk of weakening the signatures, convenience, and
the signing infrastructure can be used for other things).

Cheers,
Rusty.
-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/