David Howells <[email protected]> writes:
> Rusty Russell <[email protected]> wrote:
>
>> I noticed the Cert number didn't change with rebuilds: "distclean"
>> didn't remove some files:
>>
>> $ git clean -f -f -x -d
>> Removing extra_certificates
>> Removing signing_key.priv
>> Removing signing_key.x509
>> Removing signing_key.x509.keyid
>> Removing signing_key.x509.signer
>> Removing x509.genkey
>
> I'm not sure whether distclean should remove those, since they can be
> externally supplied, or whether x509.genkey should have a Makefile dependency
> on kernel/Makefile.
>
> I lean towards 'yes' when I'm altering kernel/Makefile trying to get things
> right, and 'no' when I'm doing a make distclean to change my config or
> changing kernel/Makefile for some unrelated reason.
Right. I think we need to use different names for generated vs supplied
files, then, because 'distclean' really must delete generated files.
But it turns out you do try to clean these files, it just doesn't work.
See below. I've applied this, as well, to my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git modules-next
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.
Cheers,
Rusty.
>From 8921e2ede91f93dcdbd08fa6613f8458de5f8afe Mon Sep 17 00:00:00 2001
From: Rusty Russell <[email protected]>
Date: Tue, 2 Oct 2012 14:35:24 +0930
Subject: [PATCH] MODSIGN: Make mrproper should remove generated files.
It doesn't, because the clean targets don't include kernel/Makefile, and
because two files were missing from the list.
Signed-off-by: Rusty Russell <[email protected]>
diff --git a/Makefile b/Makefile
index 1c88ec3..e70ebfe 100644
--- a/Makefile
+++ b/Makefile
@@ -995,7 +995,10 @@ MRPROPER_DIRS += include/config usr/include include/generated \
arch/*/include/generated
MRPROPER_FILES += .config .config.old .version .old_version \
include/linux/version.h \
- Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
+ Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
+ signing_key.priv signing_key.x509 x509.genkey \
+ extra_certificates signing_key.x509.keyid \
+ signing_key.x509.signer
# clean - Delete most, but leave enough to build external modules
#
diff --git a/kernel/Makefile b/kernel/Makefile
index 86336c9..bb94783 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -216,4 +216,3 @@ x509.genkey:
@echo >>x509.genkey "subjectKeyIdentifier=hash"
@echo >>x509.genkey "authorityKeyIdentifier=keyid"
endif
-CLEAN_FILES += signing_key.priv signing_key.x509 x509.genkey extra_certificates
Rusty Russell <[email protected]> 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
David Howells <[email protected]> writes:
> Rusty Russell <[email protected]> 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.
OK, cherry-picked to replace my hack.
It's in linux-next, and I will push in the next two days.
Thanks,
Rusty.
On Thu, Oct 4, 2012 at 2:22 AM, Rusty Russell <[email protected]> wrote:
> David Howells <[email protected]> writes:
>
>> Rusty Russell <[email protected]> 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.
>
> OK, cherry-picked to replace my hack.
>
> It's in linux-next, and I will push in the next two days.
>
http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=commit;h=a15e196c5543d1d2d7f0cd70e62351aeb1f8b871
It breaks bisect..
CC kernel/module_signing.o
kernel/module_signing.c: In function ‘mod_verify_sig’:
kernel/module_signing.c:21:10: error: ‘ENOKEY’ undeclared (first use
in this function)
kernel/module_signing.c:21:10: note: each undeclared identifier is
reported only once for each function it appears in
kernel/module_signing.c:22:1: warning: control reaches end of non-void
function [-Wreturn-type]
make[1]: *** [kernel/module_signing.o] Error 1
make: *** [kernel] Error 2
make: *** Waiting for unfinished jobs....
> Thanks,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
"Kasatkin, Dmitry" <[email protected]> writes:
> http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=commit;h=a15e196c5543d1d2d7f0cd70e62351aeb1f8b871
>
> It breaks bisect..
>
> CC kernel/module_signing.o
> kernel/module_signing.c: In function ‘mod_verify_sig’:
> kernel/module_signing.c:21:10: error: ‘ENOKEY’ undeclared (first use
> in this function)
> kernel/module_signing.c:21:10: note: each undeclared identifier is
> reported only once for each function it appears in
> kernel/module_signing.c:22:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> make[1]: *** [kernel/module_signing.o] Error 1
> make: *** [kernel] Error 2
> make: *** Waiting for unfinished jobs....
Ah, my mistake; missing #include. I've fixed this which unfortunately
meant a rebase.
Thanks,
Rusty.