linux-kernel - Fwd: MODSIGN: Modules fail signature verification with -ENOKEY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <50EFDE31.90709@csamuel.org>
Date:	Fri, 11 Jan 2013 20:41:05 +1100
From:	Chris Samuel <chris@...muel.org>
To:	linux-kernel@...r.kernel.org
CC:	Rusty Russell <rusty@...tcorp.com.au>, dhowells@...hat.com
Subject: Fwd: MODSIGN: Modules fail signature verification with -ENOKEY

/*
  * Rusty requested I send this to LKML, please CC me in on responses as
  * I am not subscribed to LKML for sanity reasons. :-)
  */

Hi Rusty, David, LKML,

I suspect this is pilot error, or a deficiency in the Debian/Ubuntu
make-kpkg scripts, but building various 3.8 kernels from before rc1
through to just before rc3 I find I always get:

Disabling lock debugging due to kernel taint

which turns out to be the result of module_sig_check() failing to
verify signatures because of -ENOKEY.

I've attached the primitive build script I'm using to make kernel
packages I use myself, and an example kernel config for the latest
build I did.

I couldn't find anything relevant in the Documentation directory, so
I'm  wondering if it's just meant to work?

I do have the signing keys:

chris@...is-ultralap:~/Code/linux$ ls -l signing_key.*
-rw-rw-r-- 1 chris chris 3272 Dec 28 13:57 signing_key.priv
-rw-rw-r-- 1 chris chris 1446 Dec 28 13:57 signing_key.x509

I've also read a couple of LWN articles about it, including the latest
from Jake not long before it was merged, but I'm not really any the
wiser on how it's meant to work from a novices point of view.. :-(

http://lwn.net/Articles/470906/

I also noticed there's nothing there to tell you why the kernel is
being  tainted, I just spotted that all my kernel modules were being
marked as  F in /proc/modules and worked backwards from there.

I'll forward a patch that adds a printk_once() when verification fails
with -ENOKEY (as others seems to end in more obvious failures) and it
emits the following:

Module verification failed, required key not present, tainting kernel
Disabling lock debugging due to kernel taint

Which will hopefully stop others wasting time wondering if something
more fundamental has gone wrong. :-)

cheers,
Chris
-- 
  Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

View attachment ".config" of type "text/plain" (136567 bytes)

View attachment "buildme" of type "text/plain" (333 bytes)