Re: RFC: sign the modules at install time

[David Howells]

Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> This was based on the complaint from Davem that the "make
> allmodconfig" build got way slower because module signing takes a
> while.
> 
> And quite frankly, the whole "extra strip and sign" thing at modpost
> time was just nasty ugly code.
> 
> Why don't we do something *much* simpler? We already have a
> conditional stripping of modules (that whole INSTALL_MOD_STRIP) logic,
> and it really simplifies everything if we just do something very
> similar for the signing of modules. At "make modules_install" time,
> exactly like the stripping is done.

>From the point of view of generating Fedora/RHEL kernel RPMs, we probably
don't want to sign even at that point.  We want to do make modules_install,
run the debuginfo generator, then strip thoroughly and *then* sign.

As I understand it, Josh Boyer has a patch based on older code that adds a
modules_sign target or something like that signs the modules in their place of
installation as a separate step.  Even that much isn't really necessary:
there's a script provided to sign a module - it isn't necessary for the kernel
build to actually do it.  You can do it manually with:

	find $install_path -name "*.ko" | while read x
	do
		strip-as-appropriate $x
		./scripts/sign-file $key $x509 $x $x
	done

This is covered in the last part of Josh's blog entry on the subject:

	http://jwboyer.livejournal.com/44787.html

> Sure, it means that if you want to load modules directly from your
> kernel build tree (without installing them),

Which I do, especially for maintaining this.  It's much easier and quicker to
boot my test machine directly out of the build tree than have to build a fresh
kernel package and, especially, install it on the test machine each time I
make a change:-).

> you'd better be running a kernel that doesn't need the signing (or you need
> to sign things explicitly). But seriously, nobody cares.

True.  The only ones who really matter are the distribution kernels (including
things like Android in that).  They represent the vast majority of users of
kernels.  Everyone else is just in the noise - myself included, I guess.

> If you are building a module after booting the kernel with the intention of
> loading that modified module, you aren't going to be doing that whole module
> signing thing *anyway*.

You are mistaken in that.  We *do* want to be able to do this.  That's why
there's an extra_certificates file.

> Signed modules make sense when building the kernel and module together, so
> signing them as we install the kernel and module is just sensible.
>
> And it really is much simpler as shown by the diffstat: 13
> insertions(+), 78 deletions(-).
> 
> It seems to work for me from my (very very limited) testing. Comments?

It's probably even better to just get rid of all the automatic module signing
stuff completely and leave the sign-file script for the builder to use
manually.  The module verification code will still be present.

It would also be nice to get rid of the key autogeneration stuff.  I'm not
keen on the idea of unparameterised key autogeneration - anyone signing their
modules should really supply the appropriate address elements.  If we aren't
signing modules automatically, we can just insert an empty certificate if one
is not supplied to make allyes/modconfig work.

Distribution kernel packaging scripts (RPM spec files for example) can do the
key generation and the module signing from within the packaging fluff by
calling the script(s) the kernel provides.

We could then, perhaps, get rid of the extra_certificates file and just have
one certificates file that is the list of certs that get compiled into the
kernel, which can be filled in by the builder - though we still need access to
the specific X.509 certificate when signing so that we can put an ID into the
signature attached to the module.

David
--
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/