Bug 219675

Summary: Collect information related to the new driver update model
Product: Red Hat Enterprise Linux 5 Reporter: Steve Conklin <sconklin>
Component: sosAssignee: Steve Conklin <sconklin>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: john
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2007-0496 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-27 12:38:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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

Jon.




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.

http://rhn.redhat.com/errata/RHBA-2007-0496.html