Bug 219675 - Collect information related to the new driver update model
Collect information related to the new driver update model
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sos (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Conklin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-14 13:27 EST by Steve Conklin
Modified: 2013-04-12 14:56 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Steve Conklin 2006-12-14 13:27:21 EST
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 15:27:55 EST
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 11:16:45 EDT
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 08:38:14 EDT
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

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