[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+5PVA5hCuTar1F=g5vgT2Cj1ZbF7w+HcWzhATUx7wFs_kuSWw@mail.gmail.com>
Date: Fri, 11 Jan 2013 08:44:23 -0500
From: Josh Boyer <jwboyer@...il.com>
To: Chris Samuel <chris@...muel.org>
Cc: linux-kernel@...r.kernel.org,
Rusty Russell <rusty@...tcorp.com.au>, dhowells@...hat.com
Subject: Re: MODSIGN: Modules fail signature verification with -ENOKEY
On Fri, Jan 11, 2013 at 4:41 AM, Chris Samuel <chris@...muel.org> wrote:
> /*
> * 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.
Check the installed modules. A simple:
hexdump -C <path to module> | tail -n 20
should be enough to tell you if the installed modules at least look like
they're signed. You should see the expected "~Module signature appended~"
string. You could also check the modules in the kernel build tree for
the same thing.
If you see the string in the kernel build tree copy, but not in the
installed copy, then something in your scripts stripped it off during the
install. You'll likely need to use the modules_sign make target on the
installed module tree.
And lastly, if you see the modules are signed in both the build tree and
the installed location and you're using an initramfs it is possible that
the initramfs creation tool is stripping the signatures. Dracut was
doing this until very recently.
> 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
That might indeed be worthwhile.
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists