Bug 295581 - Module padlock-sha has a bug in kernels >= 2.6.22.4-65.fc7 (Via C7)
Module padlock-sha has a bug in kernels >= 2.6.22.4-65.fc7 (Via C7)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 275681 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-18 19:50 EDT by Jan Andrejkovic
Modified: 2011-05-14 12:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-16 15:26:32 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)

  None (edit)
Description Jan Andrejkovic 2007-09-18 19:50:35 EDT
Description of problem:

Module padlock-sha has a bug in 2.6.22.4-65.fc7 and 2.6.22.5-76.fc7 - once
loaded the attempt to load any other module will return "Key was rejected by
service" (on Via C7 - VIA Esther).

This bug may be found in older kernels as well, however I cannot confirm when it
started.

Version-Release number of selected component (if applicable):


How reproducible: Easy ;)

Steps to Reproduce:
[machine]# /sbin/modprobe sch_cbq
[machine]# /sbin/lsmod
Module                  Size  Used by
sch_cbq                19521  0
loop                   21061  2
autofs4                24773  2
<cut>

[machine]# /sbin/modprobe padlock-aes
[machine]# /sbin/modprobe padlock-sha
[machine]# /sbin/modprobe sch_cbq
FATAL: Error inserting sch_cbq
(/lib/modules/2.6.22.5-76.fc7/kernel/net/sched/sch_cbq.ko): Key was rejected by
service

[machine]# /sbin/rmmod padlock-aes
[machine]# /sbin/rmmod padlock-sha
[machine]# /sbin/modprobe sch_cbq
[machine]#
[machine]# /sbin/modprobe sch_cbq
[machine]# /sbin/modprobe padlock-aes
[machine]# /sbin/modprobe padlock-sha
[machine]# /sbin/lsmod
Module                  Size  Used by
padlock_sha             8385  0
padlock_aes            26625  0
sch_cbq                19521  0
loop                   21061  2
autofs4                24773  2
<cut>

[machine]# /sbin/rmmod padlock-aes
[machine]# /sbin/rmmod padlock-sha
[machine]# /sbin/modprobe sch_htb
[machine]# /sbin/modprobe padlock-sha
[machine]# /sbin/modprobe sch_htb        # sch_htb is still loaded so it was OK here
[machine]# /sbin/rmmod sch_htb
[machine]# /sbin/modprobe sch_htb        #but not once it was unloaded
FATAL: Error inserting sch_htb
(/lib/modules/2.6.22.5-76.fc7/kernel/net/sched/sch_htb.ko): Key was rejected by
service
[machine]#
  
Actual results:
Once module padlock-sha is loaded, it prevents any other modules to be loaded.
In some way it creates a "lock" for other modules - quite interesting "feature"
but not really needed ;)

Expected results:
Module padlock-sha should not affect the behaviour of other modules once loaded.

Additional info:
Comment 1 Chuck Ebbert 2007-09-19 14:30:34 EDT
Are there any kernel messages in the system log when this happens?
Comment 2 Chuck Ebbert 2007-09-19 14:33:40 EDT
*** Bug 275681 has been marked as a duplicate of this bug. ***
Comment 3 Jan Andrejkovic 2007-09-19 22:30:57 EDT
I made some additional checks on 2.6.22.5-76.fc7 - just to prove any other 
module is affected once padlock-sha is loaded. The error message in logs is 
"Module signature verification failed". Once I remove padlock-sha from memory 
they work fine:

[machine]# /sbin/lsmod | grep cbq
[machine]# /sbin/modprobe padlock-sha
[machine]# /sbin/modprobe sch_cbq
FATAL: Error inserting sch_cbq (/lib/modules/2.6.22.5-
76.fc7/kernel/net/sched/sch_cbq.ko): Key was rejected by service

[machine]# /sbin/modprobe sch_cbq
FATAL: Error inserting sch_cbq (/lib/modules/2.6.22.5-
76.fc7/kernel/net/sched/sch_cbq.ko): Key was rejected by service

[machine]# /sbin/rmmod padlock-sha
[machine]# /sbin/modprobe sch_cbq
[machine]# /sbin/lsmod | grep cbq
sch_cbq                19521  0
[machine]# /sbin/modprobe padlock-sha
[machine]# /sbin/modprobe sch_cbq
[machine]# /sbin/rmmod sch_cbq
[machine]# /sbin/modprobe sch_cbq
FATAL: Error inserting sch_cbq (/lib/modules/2.6.22.5-
76.fc7/kernel/net/sched/sch_cbq.ko): Key was rejected by service
[machine]#

/var/log/messages:
Sep 20 machine kernel: padlock: Using VIA PadLock ACE for SHA1/SHA256 
algorithms.
Sep 20 machine kernel: Module signature verification failed
Sep 20 machine kernel: Module signature verification failed
Sep 20 machine kernel: padlock: Using VIA PadLock ACE for SHA1/SHA256 
algorithms.
Sep 20 machine kernel: Module signature verification failed


[machine]# /sbin/modprobe xfs
FATAL: Error inserting xfs (/lib/modules/2.6.22.5-76.fc7/kernel/fs/xfs/xfs.ko): 
Key was rejected by service
[machine]# /sbin/modprobe ext2
FATAL: Error inserting ext2 (/lib/modules/2.6.22.5-
76.fc7/kernel/fs/ext2/ext2.ko): Key was rejected by service
[machine]# /sbin/modprobe vfat
WARNING: Error inserting fat (/lib/modules/2.6.22.5-
76.fc7/kernel/fs/fat/fat.ko): Key was rejected by service
FATAL: Error inserting vfat (/lib/modules/2.6.22.5-
76.fc7/kernel/fs/vfat/vfat.ko): Key was rejected by service
[machine]# /sbin/rmmod padlock-sha
[machine]# /sbin/modprobe xfs
[machine]# /sbin/modprobe ext2
[machine]# /sbin/modprobe vfat
[machine]# 

/var/log/messages:
Sep 20 thsw kernel: Module signature verification failed
Sep 20 thsw kernel: Module signature verification failed
Sep 20 thsw kernel: Module signature verification failed
Sep 20 thsw kernel: SGI XFS with ACLs, security attributes, large block 
numbers, no debug enabled
Sep 20 thsw kernel: SGI XFS Quota Management subsystem
Comment 4 Jan Andrejkovic 2007-09-22 20:57:02 EDT
IMHO this bug can be possibly caused by module signature checking as well:

http://lkml.org/lkml/2007/2/14/169

If I have more time I try to find more exact cause...
Comment 5 Chuck Ebbert 2007-09-24 18:04:37 EDT
Module signature checking is enabled in Fedora, and somehow the via padlock
driver is breaking it. The latestFedora 7 test kernel has the tcrypt module
enabled; that should be able to tell if the SHA256 code in the Via driver is
broken. Can you test?

  1. load the via padlock driver
  2. then: modprobe tcrypt mode=303
           modprobe tcrypt mode=304

kernels are at:

http://koji.fedoraproject.org/koji/buildinfo?buildID=19274
Comment 6 Jan Andrejkovic 2007-09-30 20:48:58 EDT
I tried what you advice with your .85 version and also with latest .91 version -
still no luck:

[machine]# uname -a
Linux thsw 2.6.22.7-85.fc7 #1 SMP Fri Sep 21 19:53:05 EDT 2007 i686 i686 i386
GNU/Linux
[machine]# /sbin/modprobe padlock_sha
[machine]# /sbin/modprobe tcrypt mode=303
FATAL: Error inserting tcrypt
(/lib/modules/2.6.22.7-85.fc7/kernel/crypto/tcrypt.ko): Key was rejected by service
[machine]# /sbin/modprobe tcrypt mode=304
FATAL: Error inserting tcrypt
(/lib/modules/2.6.22.7-85.fc7/kernel/crypto/tcrypt.ko): Key was rejected by service
[machine]#
[machine]# /sbin/rmmod padlock_sha
[machine]# /sbin/modprobe tcrypt mode=303
FATAL: Error inserting tcrypt
(/lib/modules/2.6.22.7-85.fc7/kernel/crypto/tcrypt.ko): Resource temporarily
unavailable
[machine]# /sbin/modprobe tcrypt mode=304
FATAL: Error inserting tcrypt
(/lib/modules/2.6.22.7-85.fc7/kernel/crypto/tcrypt.ko): Resource temporarily
unavailable
[machine]#

--------------------------------------------------------------
[machine]# uname -a
Linux thsw 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386
GNU/Linux
[machine]# /sbin/modprobe padlock_sha
[machine]# /sbin/modprobe tcrypt mode=303
FATAL: Error inserting tcrypt
(/lib/modules/2.6.22.9-91.fc7/kernel/crypto/tcrypt.ko): Key was rejected by service
[machine]# /sbin/modprobe tcrypt mode=304
FATAL: Error inserting tcrypt
(/lib/modules/2.6.22.9-91.fc7/kernel/crypto/tcrypt.ko): Key was rejected by service
[machine]#

Jan
Comment 7 Chuck Ebbert 2007-10-01 16:49:15 EDT
(In reply to comment #6)
> I tried what you advice with your .85 version and also with latest .91 version -
> still no luck:
> 
> [machine]# uname -a
> Linux thsw 2.6.22.7-85.fc7 #1 SMP Fri Sep 21 19:53:05 EDT 2007 i686 i686 i386
> GNU/Linux
> [machine]# /sbin/modprobe padlock_sha
> [machine]# /sbin/modprobe tcrypt mode=303
> FATAL: Error inserting tcrypt
> (/lib/modules/2.6.22.7-85.fc7/kernel/crypto/tcrypt.ko): Key was rejected by
service
> [machine]# /sbin/modprobe tcrypt mode=304
> FATAL: Error inserting tcrypt
> (/lib/modules/2.6.22.7-85.fc7/kernel/crypto/tcrypt.ko): Key was rejected by
service

Yeah, we should have known the the bug itself prevents loading the module to
test the bug.
Comment 8 Jan Andrejkovic 2007-11-01 10:02:49 EDT
Hello, just an update for Kernel 2.6.23.1-10.fc7:

Problem still persists...

Jan
Comment 9 Chuck Ebbert 2007-11-01 11:17:30 EDT
We should probably not distribute that module with our kernel, since nobody can
figure out why this is happening.
Comment 10 Christopher Brown 2008-01-13 19:37:27 EST
Is it worth filing this one upstream?
Comment 11 Jan Andrejkovic 2008-01-14 04:14:26 EST
I think it is time to fix this bug finally...

I made some investigation about it. First of all it is not a bug in padlock
module itself, it is a conflict between digital signing of modules and
padlock_sha module. Or it is a bug in digital signing of modules which does not
count with the possibility to have additional external sha module.

The good thing is that once padlock_sha is loaded and problem occurs, it can be
unloaded and everything works as before.

Other findings:
- Fedora has its sha1.ko module compiled in the kernel by default - sha1.ko is
not loadable module - I think one reason for that is module digital signing
- This bug still persits in 2.6.23 fedora kernels as well.
- kernel/module-verify-sig.c contains:
        /* grab an SHA1 transformation context
         * - !!! if this tries to load the sha1.ko module, we will deadlock!!!
         */
        mvdata->hash.tfm = crypto_hash_cast(crypto_alloc_tfm2("sha1", 0, 1));
  I'm thinking if this deadlock isn't the problem which I experience once I try
to load padlock_sha module...

Some other thoughts:
- I also think what happens here is that padlock_sha is loaded into the kernel
and its module signature is to be checked by its own sha function...
The result of it is "disabled" sha function... 
- I suggest to test if sha kernel fucntion works at all once padlock_sha is
loaded...
Comment 12 Chuck Ebbert 2008-01-16 15:26:32 EST
The module signing will be removed in Fedora 9.

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