linux-kernel - Re: [GIT PULL] Asymmetric keys and module signing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <23688.1349186865@warthog.procyon.org.uk>
Date:	Tue, 02 Oct 2012 15:07:45 +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:

> Right.  I think we need to use different names for generated vs supplied
> files

The problem with supplied files is people who do allyesconfig, allmodconfig
and randconfig just to test things finding that their builds break.  The
kernel build magic is not really set up to handle external files like this.  I
suppose make logic can be used to conditionally include stuff that might not
exist.

> BTW, you missed a Signed-off-by: on your "MODSIGN: Use the same digest
> for the autogen key sig as for the module sig" patch.  Please update.

Done.

I've also added a patch to convert the system clock to a struct tm and to
produce a struct tm within the ASN.1 decode and then compare those rather than
time_t values as a way to deal with the validity time overflow problem.  We
may have to be able to handle certificates that we haven't generated that
stretch beyond 2038 (I wonder if we might find such in the UEFI key database
for example.

Another way of dealing with this could be to make mktime() within the kernel
produce a u64 rather than an unsigned long, and then compare those.

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/