Bug 219675 - Collect information related to the new driver update model
Summary: Collect information related to the new driver update model
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sos   
(Show other bugs)
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Conklin
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-12-14 18:27 UTC by Steve Conklin
Modified: 2013-04-12 18:56 UTC (History)
1 user (show)

Fixed In Version: RHBA-2007-0496
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-27 12:38:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0496 normal SHIPPED_LIVE SOS bug fix update 2007-10-31 13:43:08 UTC

Description Steve Conklin 2006-12-14 18:27:21 UTC
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.

Comment 1 Steve Conklin 2006-12-14 20:27:55 UTC
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.
* Verify.

I will look into modifying upstream to make this easier, but this
approach should work in RHEL5.0 anyway.

Any questions? :-)


Comment 2 Navid Sheikhol-Eslami 2007-03-15 15:16:45 UTC
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).

-- Navid

Comment 7 Red Hat Bugzilla 2007-06-27 12:38:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.