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) ? $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
