From: Rusty Russell <rusty@rustcorp.com.au>
To: Josh Boyer <jwboyer@redhat.com>, David Howells <dhowells@redhat.com>
Cc: herbert@gondor.hengli.com.au, pjones@redhat.com,
linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, keyrings@linux-nfs.org
Subject: Re: [GIT PULL] Asymmetric keys and module signing
Date: Tue, 02 Oct 2012 12:58:03 +0930 [thread overview]
Message-ID: <87626t4kos.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20121001204150.GA20849@hansolo.jdub.homelinux.org>
Josh Boyer <jwboyer@redhat.com> writes:
> On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:
>> Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>> > [ 2.808075] Loading module verification certificates
>> > [ 2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has expired
>> > [ 2.810500] MODSIGN: Problem loading in-kernel X.509 certificate (-127)
>>
>> Hmmm... Other people have seen that.
>>
>> Ahhhhh!
>>
>> I wonder if the problem is that the certificate is valid for 100 years....
>> That might well cause an overflow on a 32-bit system.
>
> That does seem quite plausible. The comparisons are done with time_t,
> which boils down to 'long' and 100 years in seconds would overflow
> LONG_MAX.
>
>> Could you try changing the '36500' in kernel/Makefile to something shorter,
>> like 365?
>
> I tried two values today. One close to LONG_MAX (24800 or ~68 years),
> and 10 years (3650). The former still seemed to overflow, but
> specifying a 10yr lifetime appears to have worked.
That's because the timestamp is absolute, right? Indeed, that seems to
be the limit here.
Here's my solution (tested, and it breaks if you change 2147300000 to
2147600000 as expected):
>From 2a4b91c2c29739191c6f7db9abee9296ae505c39 Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Tue, 2 Oct 2012 12:55:06 +0930
Subject: [PATCH] MODSIGN: fix expiry of auto-generated certificates on 32-bit
systems
100-year certificates make time_t wrap, resulting in:
[ 2.835272] X.509: Cert a94f6776f3f5483b0764011d1fcc6c0298362e63 has expired
[ 2.836346] MODSIGN: Problem loading in-kernel X.509 certificate (-127)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/kernel/Makefile b/kernel/Makefile
index e951adf..86336c9 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -168,6 +168,13 @@ endif
ifeq ($(sign_key_with_hash),)
$(error Could not determine digest type to use from kernel config)
endif
+ifeq ($(CONFIG_64BIT),y)
+# 100 years is beyond my best-before date, anyway.
+end_of_time_days=36500
+else
+# Until 32-bit time_t wraps, with some slack.
+end_of_time_days=$(shell expr \( 2147300000 - `date -u +%s` \) / 86400 )
+endif
signing_key.priv signing_key.x509: x509.genkey
@echo "###"
@@ -180,7 +187,8 @@ signing_key.priv signing_key.x509: x509.genkey
@echo "###"
@echo "### rngd -r /dev/hwrandom"
@echo "###"
- openssl req -new -nodes -utf8 $(sign_key_with_hash) -days 36500 -batch \
+ openssl req -new -nodes -utf8 $(sign_key_with_hash) \
+ -days $(end_of_time_days) -batch \
-x509 -config x509.genkey \
-outform DER -out signing_key.x509 \
-keyout signing_key.priv
next prev parent reply other threads:[~2012-10-02 6:31 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 0:07 [GIT PULL] Asymmetric keys and module signing David Howells
2012-09-25 0:11 ` David Howells
2012-09-25 15:09 ` Wrong system clock vs X.509 date specifiers David Howells
2012-09-25 15:30 ` Alan Cox
2012-09-25 15:35 ` David Howells
2012-09-25 15:43 ` Paolo Bonzini
2012-09-25 16:00 ` Alan Cox
2012-09-25 21:57 ` David Howells
2012-09-25 16:02 ` Tomas Mraz
2012-09-25 17:31 ` David Howells
2012-09-25 18:39 ` Tomas Mraz
2013-03-14 10:48 ` David Woodhouse
2013-03-14 12:24 ` [PATCH] Fix x509_key_preparse() not to reject keys outside their validity time range David Woodhouse
2013-03-19 21:06 ` Alexander Holler
2012-09-25 15:44 ` [GIT PULL] Asymmetric keys and module signing Kasatkin, Dmitry
2012-09-25 16:15 ` David Howells
2012-09-26 3:46 ` Rusty Russell
2012-09-26 9:09 ` David Howells
2012-09-27 0:12 ` Rusty Russell
2012-09-27 9:08 ` David Howells
2012-09-28 5:55 ` Rusty Russell
2012-09-28 8:13 ` David Howells
2012-09-28 5:58 ` [PATCH 1/2] modsign: don't use bashism in sh scripts Rusty Russell
2012-09-28 8:10 ` David Howells
2012-10-02 2:24 ` Rusty Russell
2012-09-28 5:59 ` [PATCH 2/2] modules: don't call eu-strip if it doesn't exist Rusty Russell
2012-09-28 8:11 ` David Howells
2012-09-28 6:05 ` [GIT PULL] Asymmetric keys and module signing Rusty Russell
2012-09-28 8:09 ` David Howells
2012-09-29 6:53 ` Rusty Russell
2012-09-29 7:13 ` David Howells
2012-10-01 20:41 ` Josh Boyer
2012-10-02 3:28 ` Rusty Russell [this message]
2012-10-02 12:17 ` Josh Boyer
2012-09-29 7:16 ` David Howells
2012-10-02 6:12 ` Rusty Russell
2012-10-02 14:07 ` David Howells
2012-10-03 23:22 ` Rusty Russell
2012-10-09 10:55 ` Kasatkin, Dmitry
2012-10-10 9:37 ` Rusty Russell
2012-09-28 9:23 ` David Howells
2012-09-28 10:31 ` David Howells
2012-10-03 17:50 ` [patch] MODSIGN: Fix build error with strict typechecking David Rientjes
2012-09-27 2:04 ` [GIT PULL] Asymmetric keys and module signing Mimi Zohar
2012-09-28 6:54 ` Rusty Russell
2012-09-28 6:27 ` Geert Uytterhoeven
2012-09-28 8:00 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87626t4kos.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=dhowells@redhat.com \
--cc=herbert@gondor.hengli.com.au \
--cc=jwboyer@redhat.com \
--cc=keyrings@linux-nfs.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox