Darren J Moffat wrote: > Danek Duvall wrote: >> On Mon, Jan 29, 2007 at 07:23:07PM -0800, David Powell wrote: >> >>>> However, what I'd really, really like to see is a way to embed a >>>> keyword >>>> that is taken from a build (say "snv54" or somesuch) via Makefile, for >>>> production builds, and has some other text for unofficial builds (say >>>> "debugYYYYMMDD" or somesuch). >>> Have you ever tried '::showrev -v' in mdb -k (or kmdb)? We store an >>> identifier for the build in (I believe) the CTF data for each >>> individual module. >>> >>> Accessing this from places other than mdb is definitely possible. >> >> If nothing else: >> >> installed-machine$ what /kernel/drv/sparcv9/fbt >> /kernel/drv/sparcv9/fbt: >> SunOS 5.11 snv_49 October 2007 >> >> bfued-machine$ what /kernel/drv/sparcv9/fbt >> /kernel/drv/sparcv9/fbt: >> SunOS 5.11 onnv-gate:2007-01-26 October 2007 >> SunOS Internal Development: gk 2007-01-26 [onnv-gate] >> >> But is that good enough for Services, or is it critical that the data >> be in >> the modinfo output? > > What problem is this actually attempting to solve ? > > If the problem is identifying where the binary came from then > the fingerprint database stored on sunsolve.sun.com solves that > problem using MD5 hashes of the files. It does however only work for > Solaris not all distros. It works for all officially distributed > bits, including patches and releases back at least as far as 2.5.1 and > some unbundled products as well. > > Another way to find out if the binary is "official" and not rouge is > to use elfsign(1) verify. I don't believe distros other than Sun's > sign non crypto binaries - but they could if the wanted to (the > instructions for doing so are on my blog). > > We also have the /system/object file system where you can check hashes > of the currently in kernel files. > > My vote is to remove ALL version numbers from kernel modules they > aren't actually meaningfull in my opinion. > > The output of what(1) on the other hand is reasonable to keep. >
Hmm... /system/object sounds interesting, but a quick test shows that the binaries there do not give the same checksums as the objects on disk. (At least as I tested this on my Sun Blade 100 running S10u2. Possibly this has changed in Nevada.) Also, elfsign verify doesn't work on these object files, for some reason. Here are the problems that I think we need to solve: 1. We need a way to compare the objects in memory with what is on disk 2. We need a way to determine the source of an object (who built it). 3. We need a way to determine the source code an object is derived from. (Patch, release, etc.) 4. We need an easy way for end-users to get the above information. I suggest that for kernel objects, this information (all of it) could be provided by modinfo(1M), satisfying requirement #4. (mdb is a bit unwieldy as an end-user tool for novice admins.) I suggest that checksums (md5, or better yet, sha2) could be run over in-core objects and on-disk objects. This could solve #1. These could be the same hash values used by elfsign(1). (Again, I'd use a switch to modinfo to get this information.) Doing the same thing as elfsign(1) or what(1), and providing switches in modinfo(1m) solves #2 and #3. Given these, I think it is obvious that the %I% in modinfo output is not terribly useful and should just go away. But right now it isn't clear to me that we have item 1 solved yet. (sure there is mdb ::showversion, but that is not well known, and doesn't work against on-disk objects.) -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
