Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp268127imm; Tue, 17 Jul 2018 18:44:42 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdU2dEp32IDnQtJZtakls7zvhLEeoaDeSGovkX+O8ZJoMed/z4/tdFc68SE8a0L672IBTGE X-Received: by 2002:a65:638a:: with SMTP id h10-v6mr3848138pgv.269.1531878282617; Tue, 17 Jul 2018 18:44:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531878282; cv=none; d=google.com; s=arc-20160816; b=wu29hS/ns93mM+NmITRK1NL+5/kTbWsoA1RS0j855B578tcJ4Qcugssy4CqrfoM3Iw AzsJ8jAm36JCnk0IeviZawRwoX2eVvGWx8lCgYrr2n2QBmFgeo66twpsS+mCfyxKFBy4 86A+NwPzlCuX8wobkTKIi5NWzhL6yFNFNQfb1scp3Evl/2XHjEWwGqK3NXRFeTyLaz+b RvVqjJfErll/AtwFq7vkjqaCcc5BIJ/7q3m2xOriOJox7P137RQXtqSa1KEomCOOuJXc glnSNySd0xNg75z6loMRGG+xU96v6mso6QjG4pYMjkB2B37TZlj1Ehf65fJzkgEdl90s 9cqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=/6kW4C0AuE1PrIVo8C3EcpCflI1vVjKQKVIBShAGxC0=; b=t/kp7hv4x8IkA33SMyWRhJ8r6nXhVa9AVKxBqJXbpKlQVg1C7tjY8eh6hVFc61510T u+lKX/xRnD+C9O37h3UOHq7BS69KJTHRfZGrAUyPKiKaX2ddCF1dzDaGurrJ4yCppGJ8 4ByMghB8vwaXwqDG/5PwQ1JI6qUCKRWosh2w7jIz2b3Xy+UZIgbWyEUY5y/DCeVA5061 /jYysO2jac5QPCRJMNdr+1iAICbNVpdgrFBU6nvV4Irt3bHMR3jt4w6Ot/YyZXamxA2c 6FL7UDB5MFhbMM+yeArukwJUzvfAc8HifzG4o54hBqLi26xVQ3J2lLVa9qdcymo6MHWB 2XZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=JXLzSQV2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i1-v6si1978548plt.183.2018.07.17.18.44.27; Tue, 17 Jul 2018 18:44:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=JXLzSQV2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731624AbeGRCTP (ORCPT + 99 others); Tue, 17 Jul 2018 22:19:15 -0400 Received: from imap.thunk.org ([74.207.234.97]:54446 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730614AbeGRCTP (ORCPT ); Tue, 17 Jul 2018 22:19:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/6kW4C0AuE1PrIVo8C3EcpCflI1vVjKQKVIBShAGxC0=; b=JXLzSQV2OIijEzrDdTnZKshaMn wdRzEy++A2t3tr6TYe6cZd6JLUo8yAQ34U61Mjhe6EySGvemc+D5nN6lmVHQT98C8gtICVLPHEXF/ Khenbizd88EQvjXAHJIK9f/xdb/+Q55tWfgbCiBm8ZJC3tZc45HOE4gNdg/PjD7wexVQ=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1ffbVQ-0000lp-Mh; Wed, 18 Jul 2018 01:43:52 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8E3DB7A63F0; Tue, 17 Jul 2018 21:43:50 -0400 (EDT) From: Theodore Ts'o To: linux-crypto@vger.kernel.org, Linux Kernel Developers List Cc: labbott@redhat.com, Theodore Ts'o Subject: [PATCH] random: add a config option to trust the CPU's hwrng Date: Tue, 17 Jul 2018 21:43:44 -0400 Message-Id: <20180718014344.1309-1-tytso@mit.edu> X-Mailer: git-send-email 2.18.0.rc0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This gives the user building their own kernel (or a Linux distribution) the option of deciding whether or not to trust the CPU's hardware random number generator (e.g., RDRAND for x86 CPU's) as being correctly implemented and not having a back door introduced (perhaps courtesy of a Nation State's law enforcement or intelligence agencies). This will prevent getrandom(2) from blocking, if there is a willingness to trust the CPU manufacturer. Signed-off-by: Theodore Ts'o --- I'm not sure Linux distro's will thank us for this. The problem is trusting the CPU manfuacturer can be an emotional / political issue. For example, assume that China has decided that as a result of the "death sentence" that the US government threatened to impose on ZTE after they were caught introducing privacy violating malware on US comsumers, that they needed to be self-sufficient in their technology sector, and so they decided the needed to produce their own CPU. Even if I were convinced that Intel hadn't backdoored RDRAND (or an NSA agent backdoored RDRAND for them) such that the NSA had a NOBUS (nobody but us) capability to crack RDRAND generated numbers, if we made a change to unconditionally trust RDRAND, then I didn't want the upstream kernel developers to have to answer the question, "why are you willing to trust Intel, but you aren't willing to trust a company owned and controlled by a PLA general?" (Or a company owned and controlled by one of Putin's Oligarchs, if that makes you feel better.) With this patch, we don't put ourselves in this position --- but we do put the Linux distro's in this position intead. The upside is it gives the choice to each person building their own Linux kernel to decide whether trusting RDRAND is worth it to avoid hangs due to userspace trying to get cryptographic-grade entropy early in the boot process. (Note: I trust RDRAND more than I do Jitter Entropy.) drivers/char/Kconfig | 14 ++++++++++++++ drivers/char/random.c | 11 ++++++++++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 212f447938ae..fe2930c4ecf0 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -554,3 +554,17 @@ config ADI endmenu +config RANDOM_TRUST_CPU + bool "Trust the CPU manufacturer to initialize Linux's CRNG" + depends on (X86 || X86_64 || X86_32 || S390 || PPC) + default n + help + Assume that CPU manufacurer (e.g., Intel or AMD for RDSEED or + RDRAND, IBM for the S390 and Power PC architectures) is trustworthy + for the purposes of initializing Linux's CRNG. Since this is not + something that can be indepedently audited, this amounts to trusting + that CPU manufacturer (perhaps with the insistance or requirement + of a Nation State's intelligence or law enforcement agencies) + has not installed a hidden back door to compromise the CPU's + random number generation facilities. + diff --git a/drivers/char/random.c b/drivers/char/random.c index 34ddfd57419b..f4013b8a711b 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -782,6 +782,7 @@ static void invalidate_batched_entropy(void); static void crng_initialize(struct crng_state *crng) { int i; + int arch_init = 1; unsigned long rv; memcpy(&crng->state[0], "expand 32-byte k", 16); @@ -792,10 +793,18 @@ static void crng_initialize(struct crng_state *crng) _get_random_bytes(&crng->state[4], sizeof(__u32) * 12); for (i = 4; i < 16; i++) { if (!arch_get_random_seed_long(&rv) && - !arch_get_random_long(&rv)) + !arch_get_random_long(&rv)) { rv = random_get_entropy(); + arch_init = 0; + } crng->state[i] ^= rv; } +#ifdef CONFIG_RANDOM_TRUST_CPU + if (arch_init) { + crng_init = 2; + pr_notice("random: crng done (trusting CPU's manufacturer)\n"); + } +#endif crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1; } -- 2.18.0.rc0