Bug 215664 - ksign mismatch GPG key for signed kernel modules
Summary: ksign mismatch GPG key for signed kernel modules
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Howells
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-15 03:05 UTC by John Reiser
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-11-17 05:16:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
serial console log from .2849 (fails) (11.08 KB, text/plain)
2006-11-15 03:05 UTC, John Reiser
no flags Details
serial console log from .2798 (succeeds) (15.35 KB, text/plain)
2006-11-15 03:07 UTC, John Reiser
no flags Details

Description John Reiser 2006-11-15 03:05:16 UTC
Description of problem: kernel 2.6.18-1.2849.fc6 installs public key 
D40D77874EB40D76 but the modules are signed with key 4d36eef71c3a3150 so signed
modules fail to load.


Version-Release number of selected component (if applicable):
kernel-2.6.18-1.2849.fc6


How reproducible: Always


Steps to Reproduce:
1. boot 2.6.18-1.2849.fc6
2.
3.
  
Actual results: signed kernel modules fail to load because the loaded key is
different.


Expected results: signed kernel modules succeed to load.


Additional info: kernel-2.6.18-1.2798.fc6 succeeds on same root and machine. 
Will attach serial console logs from bad and good boots.

Comment 1 John Reiser 2006-11-15 03:05:16 UTC
Created attachment 141211 [details]
serial console log from .2849 (fails)

Comment 2 John Reiser 2006-11-15 03:07:12 UTC
Created attachment 141212 [details]
serial console log from .2798 (succeeds)

Comment 3 John Reiser 2006-11-15 04:23:49 UTC
The last 6 modules which fail to load are ehci-hcd.ko, jbd.ko, ext3.ko,
scsi_mod.ko, libata.ko, sata_nv.ko; 3 others have scrolled off the vga console.
 A typical message is "insmod: error inserting '/lib/jbd.ko': -1 Operation not
permitted"; and that does not appear in the serial console log because it comes
from insmod, not from the kernel.  [Note that "modules/2.6.18-1.2849.fc6/" is
missing from the filename.  The files are in /lib/modules/2.6.18-1.2849.fc6/... ]

Comment 4 Dave Jones 2006-11-17 03:24:59 UTC
that's really bizarre.

objdump -s .module_sig
/lib/modules/2.6.18-1.2849.fc6/kernel/drivers/scsi/libata.ko shows me ...

Contents of section .module_sig:
 0000 883f0305 004554bc 80d40d77 874eb40d  .?...ET....w.N..
 0010 76110274 18009f5e c64eae0a 0e14c87b  v..t...^.N.....{
 0020 7dd1626e acf5b1ee b44bdb00 9f489259  }.bn.....K...H.Y
 0030 3cee007f f90f04d5 d27aff78 895c708d  <........z.x.\p.
 0040 5c 

which shows it clearly has the right key.
Can you confirm your on-disk modules are the same ?

It's really unusual that you're the only person to have hit this. If the signs
were bad, it would break for everyone.

Comment 5 John Reiser 2006-11-17 05:16:31 UTC
Operator error [egg on face]: the old initrd was loaded with the new kernel. 
The missing "modules/2.6.18-1.2849.fc6/" in "/lib/jbd.ko" is even a clue that
the module was being loaded from initrd and not from the regular on-disk root
filesystem directory.

I had help in not seeing the forest for the trees.  There was no message
containing the word 'initrd', no explicit warning for initrd not matching the
kernel, no name of the initrd in the log.

How I erred:  The box boots multiple versions of Fedora Core and RHEL from
different root filesystems.  A common boot partition containing kernels and
initrds from all systems has problems because SELinux attributes are
incompatible between different systems.  A common /boot also tends to accumulate
stale files as partitions are erased and re-used.  So although I do have a boot
partition that contains GRUB itself and a master grub.conf, each kernel and
initrd lives in its respective root filesystem.  /boot is always a regular
directory, and not a mount point.  This means that the GRUB changes from "yum
update kernel" must be forwarded from the local grub.conf to the master
grub.conf; the error occured in forwarding.  Perhaps "double GRUB" would avoid
this problem: The first GRUB just selects which root, and loads the second GRUB
from the beginning of that partition, which then allows choosing only those
kernels that reside on that particular root.


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