The information required to determine whether drievrs were delivered by Red Hat
needs to be added. This needs to support the new driver delivery model.
Here's information from an ongoing email thread, to capture it.
On Tue, 2006-12-12 at 16:37 -0500, Jon Masters wrote:
> > Steve Conklin wrote:
>> > > Jon, I'm unfamiliar with the new model. What's required in order to
>> > > capture this information?
> > Ok. So here's the overview (I'll send some more later):
More information. Please followup now to make sure that you get this and
have all that is needed to modify sos.
> > * If we supply a kernel module (.ko file) in the kernel package, then it
> > is signed (the ELF binary itself) using the per-build GPG key.
You hopefully already have this logic. If not:
* Pull out the .module_sig ELF section from a module .ko file. Read this
signature, compare (using GPG) with the Red Hat signing key.
> > * If we supply a kernel module (.ko file) outside the kernel package,
> > then readlink on the .ko file should point to an /extra subdirectory
> > containing a .ko file that belongs to an RPM signed by us.
We didn't sign the .ko file but it should be located in a sane location
(always /lib/modules/kernel_version_it_was_built_for/extra/module.ko -
but the module loaded might be a symlink to that file, so readlink) and
we should have signed the RPM that it contains with an RH key.
> > * If we do not supply a kernel module (.ko file) then it is neither
> > signed by us, nor is the RPM package containing it.
Average case with third party packaged module(s).
> > In the case that the user has played around with their system since
> > booting, the current loaded driver may differ from the state on disk -
> > in this case, we can look at e.g. the current kernel symbol table to
> > figure out what is loaded - I'll send you an example tonight.
You should always verify that the module loaded matches on disk. To do
this you can e.g.:
* Run modinfo against the module that is on disk. Get the srcversion.
* Read /sys/module/module_name/srcversion.
I will look into modifying upstream to make this easier, but this
approach should work in RHEL5.0 anyway.
Any questions? :-)
After a conversation with dhowells and jcm, currently there's no easy way to
check the signature of a module outside of kernel-space.
I will look into converting the kernel internal routines to a usable C library
to perform this check within sosreport.
I've also committed to SVN some code that compares the loaded module with the
local file-system version to see if they are the same (revision 99).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.