Bug 215664 - ksign mismatch GPG key for signed kernel modules
ksign mismatch GPG key for signed kernel modules
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Howells
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-14 22:05 EST by John Reiser
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-17 00:16:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description John Reiser 2006-11-14 22:05:16 EST
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-14 22:05:16 EST
Created attachment 141211 [details]
serial console log from .2849 (fails)
Comment 2 John Reiser 2006-11-14 22:07:12 EST
Created attachment 141212 [details]
serial console log from .2798 (succeeds)
Comment 3 John Reiser 2006-11-14 23:23:49 EST
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-16 22:24:59 EST
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 00:16:31 EST
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.