Rusty Russell <rusty@xxxxxxxxxx> wrote: > > > Sure, you now need to re-append that after stripping, but that's not the > > > kernel's problem. > > > > You may also have to remove the signature before passing it to any > > binutils tool lest it malfunction on the trailer > > Well, you're already on your own if you're using non-module-init-tools > tools on modules. The distributions packaging tools and initramfs tools are things I have to contend with, and others will have to contend with. > (We'll want to enhance modinfo, at least, to show the signatures). Ummm... To show what exactly? And why? The modinfo has to go into the signature hash. Further to find the modinfo, you have to parse the ELF - which brings us right back to how do you know you can trust it? > > I've found that rpmbuild and mkinitrd alter the module files at > > various times, so you'd need a bunch of signatures, one for each (may > > just be two, but I can't guarantee that). This means the kernel build > > process needs to know what transformations are going to be applied to > > a module - something that has changed occasionally within the > > distribution I use and may vary between distributions (or even just > > someone building for themselves). > > Yes, there may be more than stripped and unstripped. You may need to > do fancy things. But now, adding a signature is so easy that it's not a > real problem. And we can always have a hook, like: > > if VARIANTS=`make-module-variants $MOD`; then > for m in $VARIANTS; do sign $m >> $MOD; rm $m; done > fi That's not very practical. That spreads the what-do-we-need-to-calculate question over a whole bunch of packages: the kernel, rpmbuild (if RPM-based), mkinitramfs and maybe others. I presume you're thinking of trying all the possible strip combinations and generating a signature for each? However, if someone upgrades their binutils, but not their kernel, say, and then their initramfs gets rebuilt for some reason, this may invalidate all their module signatures. So the number of signatures is: strip_combos × binutils_variations × other_factors and you have to generate all these at kernel build time because the secret key cannot be disseminated to the installed machines that might be affected by this. (Note that binutils may rearrange the symbol, relocation and section tables in different ways for different versions.) David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
