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 _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
