On Tue, Jul 08, 2008 at 06:11:30PM +0100, Darren J Moffat wrote: > Jonathan Adams wrote: > >On Tue, Jul 08, 2008 at 03:30:01PM +0100, Darren J Moffat wrote: > >>Milan Jurik wrote: > >>>I could hack it to the module by some Makefile, but it will change > >>>revision in every build, not good for new packaging system I think. > >>It seems to me that the simplest solution here is to have at least the > >>.SUNW_signature section in a kernel crash dump and in a userland core > >>file. That means no new build process and it works for all > >>consolidations that have their binaries signed and any 3rd party code > >>that is also signed. See 6365439 which I logged on 2005-12-20. > >> > > > >I agree that having the signatures available might be good, we do already > >have this information with ::showrev -v, right? And it's perfectly usable? > > > >Out of curiosity, do the signatures have the same version information that > >the CTF data does? > > The signatures I'm talking about are the ones in .SUNW_signature. These > are a sha1 hash over the SHF_ALLOC ELF sections[1]. That sha1 hash is > then signed with an RSA private key and certificate. > > There is no relationship between the .SUNW_signature and .SUNW_ctf sections. > > The CTF data might actually be useful in determining the "version" of > modules too - but IIRC CTF isn't completely deterministic right (but > that might not matter here) ?
The CTF data includes the VERSION information from the build; run: echo "::showrev -v" | mdb -k which will display all of your modules, sorted by their CTF version strings. In a patched kernel, the patched modules will have CTF versions which include their patch-id. Cheers, - jonathan > $SRC/lib/libelfsign has the code that does this. > > [1] for historical reasons crypto framework modules are actually over > all sections - this may change in the future but is actually a useful > side effect at the moment. > > -- > Darren J Moffat
