[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <27378.1348819793@warthog.procyon.org.uk>
Date: Fri, 28 Sep 2012 09:09:53 +0100
From: David Howells <dhowells@...hat.com>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: dhowells@...hat.com, herbert@...dor.hengli.com.au,
pjones@...hat.com, jwboyer@...hat.com,
linux-crypto@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Re: [GIT PULL] Asymmetric keys and module signing
Rusty Russell <rusty@...tcorp.com.au> wrote:
> And after those three fixes, I still get all fail:
>
> [ 3.361036] Request for unknown module key 'Magrathea: Glacier signing key: 6
> e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11
Can you look back further in your kernel output, see if you can spot the bit
where it's trying to load the keys. Look for things from modsign_pubkey.c:
pr_notice("Loading module verification certificates\n");
...
pr_err("MODSIGN: Problem loading in-kernel X.509 certificate (%ld)\n",
PTR_ERR(key));
else
pr_notice("MODSIGN: Loaded cert '%s'\n",
key_ref_to_ptr(key)->description);
> CONFIG_CRYPTO_SHA1=m
Hmmm... I suspect it's that. We need a hash to verify the key's own
signature too - and if you're using the key my autogen patch created for you,
I think that would be SHA1, so that must be built in too.
If you can see your kernel log (assuming a panic doesn't prevent you), I
suspect you'll see something like:
MODSIGN: Problem loading in-kernel X.509 certificate (-65)
which is -ENOPKG.
The answer would be to either select SHA1 in Kconfig or, if possible, to tell
openssl to use the same hash algorithm to sign the key as we're going to use
in signing the modules.
David
--
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