Rusty Russell <rusty@xxxxxxxxxx> wrote: > I think you misunderstand, I'm talking about the modinfo command, not > the .modinfo section. Sorry, yes. But why do you need to enhance modinfo? > But I need to know exactly what these version-dependent mangling of > modules is. Is it real? Is it more than strip? Is it so hard to fix > that it makes sense to add 450 lines of dense kernel code to allow > alteration of a module after signing? The strip program (as far as I know that's the only binutil that we need worry about) rearranges and reorders the section, symbol and relocation tables when it discards stuff, and different versions of strip have done it differently. There's GNU build ID. gcc/binutils was changed at some point to insert an ELF note with the time at which the binary was built (something to do with debuginfo matching, I think), and strip would update this when run on the binary. I haven't encountered many other things introducing breakage that wasn't the fault of the tool doing the breaking - which usually got fixed pretty quickly. However, you said it should be fairly easy to jump over the ELF parcel to get to the signature. How do you plan on doing that? I presume you would just parse sufficient of the ELF to find the theoretical ELF EOF and then look there for a whole string of signatures - and hope they haven't got removed by some unanticipated tool before you see the module. 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
