modsign vs build-id

[Roland McGrath]

I fixed this in rawhide kernel.spec over the weekend and left a somewhat
detailed comment in the changed bit.  But I thought I'd bring this up
directly and explain the story.

The short version of What Broke is "what, you sha1 on me? no, i sha1 on you!"

Module signing works by feeding all the allocated sections of the .ko into
gpg and adding that signature to the .ko as the .module_sig section.  The
build ID note now included in each .ko when first built is an allocated
section, so its contents contribute to that signature.  

As explained somewhere down the middle of [1], debugedit (the workhorse of
find-debuginfo.sh) recomputes fresh build ID bits after editting the
debuginfo, and edits the build ID bits in the object.  This final build ID
is computed with sha1 on most of the contents of the editted binary
(including debuginfo).  It's done this way to ensure that repeating the
same rpmbuild twice with all the same constituents in the buildroot yields
identical binaries both times (with the same build IDs), unaffected by the
differences that debugedit removes, like the $RPM_BUILD_DIR name.

In the old procedure, the modules were signed in place after being built.
Then find-debuginfo.sh comes along at the end of the build, and edits the
build ID bits in each .ko.  Pow, the signature does not match the contents.

The first fix I tried was changing module signing and verification so it
skips allocated SHT_NOTE sections, which the build ID is.  That worked.
But that is not so hot in two ways.  One, the signature is not serving as
guarantor of the trustability of the module->build ID association.  Worse,
since the final build ID bits depend on everything in the installed
.ko--including the .module_sig section--now repeated builds get different
build IDs for the identical code compiled from identical sources.

So I punted that.  What kernel.spec now does is to sign the stripped .ko
files only at the very end, after find-debuginfo.sh has done its work.
This requires some spec macro hackery to get in at the right spot.  Now a
repeated build will still generate a new module-signing key and different
signatures every time.  But the build ID bits inside the signed modules
will be the same every time.  Now you know if a module got loaded with no
unsigned taint, then the build ID bits it claims to have really are those
the kernel packager wanted you to see.  (Not that this is worth a lot.)

Incidentally, if someone wants to freshen up the modsign patches, I think
it would be better to change the format slightly.


Thanks,
Roland


[1] http://fedoraproject.org/wiki/RolandMcGrath/BuildID