Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846AbbEAVlw (ORCPT ); Fri, 1 May 2015 17:41:52 -0400 Received: from 66.63.173.11.static.quadranet.com ([66.63.173.11]:49209 "EHLO q1.ich-9.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750951AbbEAVlv (ORCPT ); Fri, 1 May 2015 17:41:51 -0400 From: Abelardo Ricart III To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, sedat.dilek@gmail.com, dhowells@redhat.com, keyrings@linux-nfs.org, rusty@rustcorp.com.au, linux-security-module@vger.kernel.org, james.l.morris@oracle.com, gregkh@linuxfoundation.org, Abelardo Ricart III Subject: Re: [PATCH] MODSIGN: Change default key details [ver #2] Date: Fri, 1 May 2015 17:41:45 -0400 Message-Id: <1430516505-4812-1-git-send-email-aricart@memnix.com> X-Mailer: git-send-email 2.3.7 In-Reply-To: References: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - q1.ich-9.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - memnix.com X-Get-Message-Sender-Via: q1.ich-9.com: authenticated_id: aricart@memnix.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2413 Lines: 40 Forgive me if this git send-email blows up in my face somehow, as I hadn't been subscribed to this list before this reply. I had some similar and probably related behavior I submitted a patch to the kbuild guys for that fell on deaf ears. Basically, I think an order-only prerequisite would make the most sense in this case because right now the key generation target is going to trigger any time the x509.genkey file has its timestamp touched to where it becomes "newer" than our keys, even if its content remains the same. What if I provided my own keys already, as module-signing.txt said was okay? What if the autogenerated keys from my last build still exist? >From module-signing.txt: > Under normal conditions, the kernel build will automatically generate a new > keypair using openssl if one does not exist in the files: > > signing_key.priv > signing_key.x509 Nope, sorry, not true. Even if your keys exist, due to unfortunate parallel make/disk write order/racy kbuild/goblins your x509.genkey file has a newer timestamp than your keys, and now your keys are going to get tossed (regenerated and overwritten, yay!). Worse still, I think they could even get tossed AFTER the build decides "hey nice keys, I'll just use those". Either way, this patch is ultimately correct because this is exactly the kind of racy scenario order-only prerequisites was made for. We should not care anything about x509.genkey if our signing keys already exist. Period. Here's my two-line patch strictly defining the build order, for your perusal. Signed-off-by: Abelardo Ricart III --- diff --git a/kernel/Makefile b/kernel/Makefile index 1408b33..10c8df0 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -168,7 +168,8 @@ ifndef CONFIG_MODULE_SIG_HASH $(error Could not determine digest type to use from kernel config) endif -signing_key.priv signing_key.x509: x509.genkey +signing_key.priv signing_key.x509: | x509.genkey + $(warning *** X.509 module signing key pair not found in root of source tree ***) @echo "###" @echo "### Now generating an X.509 key pair to be used for signing modules." @echo "###" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/