lkml.org 
[lkml]   [2012]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Asymmetric keys and module signing
On Tue, Oct 02, 2012 at 12:58:03PM +0930, Rusty Russell wrote:
> 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.

Yep.

> 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

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


\
 
 \ /
  Last update: 2012-10-02 15:01    [W:0.073 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site