Re: [GIT PULL] Asymmetric keys and module signing
From: Josh Boyer <hidden>
Date: 2012-10-02 12:17:17
Also in:
lkml
On Tue, Oct 02, 2012 at 12:58:03PM +0930, Rusty Russell wrote:
Josh Boyer [off-list ref] writes:quoted
On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:quoted
Rusty Russell [off-list ref] wrote:quoted
[ 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.quoted
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.
Yep.
quoted hunk ↗ jump to hunk
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 <redacted> 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 <redacted>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
That would likely work just fine. David actually has another patch that makes 100yrs still work on 32-bit as well that I've tested locally in a KVM instance. He was waiting on positive testing confirmation from me so hopefully he'll send it soon. josh