Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp1437925imw; Sat, 9 Jul 2022 04:38:03 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sqKQPyKzZZ9Folfe6MTVQOuAPQE16EzaCnLS7uK3nawvB4F6Z21umI8/pp5rGa+6yOUq0F X-Received: by 2002:a17:903:1ca:b0:16a:5d7f:182f with SMTP id e10-20020a17090301ca00b0016a5d7f182fmr8275878plh.88.1657366683420; Sat, 09 Jul 2022 04:38:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657366683; cv=none; d=google.com; s=arc-20160816; b=k7h4JyITSQal39TGilzr7sHg9bWfTLkTK6oZtesRhu690C+kmZOHe+MAHIxRIim82h 1scj3hG2OHog1GE57eO7DbRHultBVPY0jSa9TOrS3WBnIRKnfbm+fV2Lh/rWrvpkTQAL 0ApRyxi92uD4kJZUJQkCvVof9AVi5G7TMAvK/jXj6yp0ILRnmaKhtndCYkUWWbnPZAb9 mgxVy9iZAK1l2/KfDi4u1R28tg1Aaddp7eCrFfp24V/6p8pkA+i0/AtFkOVPTvzCyajL zds4UZQELhbFliM1Imr1aa+H8qlnEzN5RNIER5woxf2g6WwJb/wACs1FF5hZ62RL6JbT 8GjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=lzyMyjvFc8oEQOd1Q98Oicc0vZlBQqMjpraSkeptarc=; b=YYA2x8OMwdRuaF28yR7cvOLwMdZDwo5wYXIjGmw0ug7ja3xjnN+zeFya3njtezavuE MGSnolr/g1kjYI07Lt7el3X+1Mmm2JaEBO+wSyMB5+HDX6LRidz5Z7svwQ/0xfL4oBKr VAZkl37cuSA2Yb3ejymNLJe5pzxkPx6WsiSCEafgDxqyCWglDL0NHWTq/Q7GWpdLV6+g XiqVRBXG9P3WoUvtAg7GK/mjKr9f+jyQLwnSZpANSGqZX85dM4t4vq+sQ+HSsiA0xETz 8GI4/+Xis9Pyee4yHHV97WrjXSbImewzi13yXICOjwKhA5WMq8FUzqg+c3O0HAA9uM5C 0QMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=guVCJgFW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n4-20020a170902e54400b0016a22de096bsi2012725plf.337.2022.07.09.04.37.49; Sat, 09 Jul 2022 04:38:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=guVCJgFW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229566AbiGIKnT (ORCPT + 99 others); Sat, 9 Jul 2022 06:43:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbiGIKnS (ORCPT ); Sat, 9 Jul 2022 06:43:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47319220C7 for ; Sat, 9 Jul 2022 03:43:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DB63060F1A for ; Sat, 9 Jul 2022 10:43:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D291C3411C; Sat, 9 Jul 2022 10:43:15 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="guVCJgFW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1657363393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lzyMyjvFc8oEQOd1Q98Oicc0vZlBQqMjpraSkeptarc=; b=guVCJgFWTYLUgq4lQ6UirU7h1CxAWLV+hen4jVO+Z2NkKvpN168r/2GI4HHJWo1j2YzXO/ jNO9Rg3DCo34K8tNQMh0P4rISWk/iMuOJC3pQ9/fwKK8cJOm81bg0M7Q6Ou2G2xWoh7zDI +/eDT/KIxCW8r5ul9QcM5nS6zP35MWg= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 7df516bf (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sat, 9 Jul 2022 10:43:13 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org Cc: "Jason A. Donenfeld" , x86@kernel.org, Theodore Ts'o , "H . Peter Anvin" , Borislav Petkov Subject: [PATCH random v2] x86/rdrand: Remove "nordrand" flag in favor of "random.trust_cpu" Date: Sat, 9 Jul 2022 12:43:06 +0200 Message-Id: <20220709104306.1094431-1-Jason@zx2c4.com> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The decision of whether or not to trust RDRAND is controlled by the "random.trust_cpu" boot time parameter or the CONFIG_RANDOM_TRUST_CPU compile time default. The "nordrand" flag was added during the early days of RDRAND, when there were worries that merely using its values could compromise the RNG. However, these days, RDRAND values are not used directly but always go through the RNG's hash function, making "nordrand" no longer useful. Rather, the correct switch is "random.trust_cpu", which not only handles the relevant trust issue directly, but also is general to multiple CPU types, not just x86. However, x86 RDRAND does have a history of being occasionally problematic. Prior, when the kernel would notice something strange, it'd warn in dmesg and suggest enabling "nordrand". We can improve on that by making the test a little bit better and then taking the step of automatically disabling RDRAND if we detect it's problematic. Also extend the basic sanity test to RDSEED in addition to RDRAND, and disable both if either one fails. Cc: x86@kernel.org Cc: Theodore Ts'o Suggested-by: H. Peter Anvin Suggested-by: Borislav Petkov Signed-off-by: Jason A. Donenfeld --- This is a tip-ish commit, but it relies on the CONFIG_ARCH_RANDOM commit in the random tree, so I'll take this through the random tree to avoid conflicts. Changes v1->v2: - [Borislav] Reformat into tip-style commit to be taken through random tree. - [Randy] Fix typos. .../admin-guide/kernel-parameters.txt | 5 -- arch/x86/kernel/cpu/amd.c | 2 +- arch/x86/kernel/cpu/rdrand.c | 73 +++++++++---------- 3 files changed, 36 insertions(+), 44 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2522b11e593f..a1dc4dbf74f6 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3733,11 +3733,6 @@ noreplace-smp [X86-32,SMP] Don't replace SMP instructions with UP alternatives - nordrand [X86] Disable kernel use of the RDRAND and - RDSEED instructions even if they are supported - by the processor. RDRAND and RDSEED are still - available to user space applications. - noresume [SWSUSP] Disables resume and restores original swap space. diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 0c0b09796ced..8baf312e030a 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -808,7 +808,7 @@ static void clear_rdrand_cpuid_bit(struct cpuinfo_x86 *c) return; /* - * The nordrand option can clear X86_FEATURE_RDRAND, so check for + * The self-test can clear X86_FEATURE_RDRAND, so check for * RDRAND support using the CPUID function directly. */ if (!(cpuid_ecx(1) & BIT(30)) || rdrand_force) diff --git a/arch/x86/kernel/cpu/rdrand.c b/arch/x86/kernel/cpu/rdrand.c index 8f216669ecb8..6f4b196fe97d 100644 --- a/arch/x86/kernel/cpu/rdrand.c +++ b/arch/x86/kernel/cpu/rdrand.c @@ -11,54 +11,51 @@ #include #include -static int __init x86_rdrand_setup(char *s) -{ - setup_clear_cpu_cap(X86_FEATURE_RDRAND); - setup_clear_cpu_cap(X86_FEATURE_RDSEED); - return 1; -} -__setup("nordrand", x86_rdrand_setup); - /* * RDRAND has Built-In-Self-Test (BIST) that runs on every invocation. - * Run the instruction a few times as a sanity check. - * If it fails, it is simple to disable RDRAND here. + * Run the instruction a few times as a sanity check. Also make sure + * it's not outputting the same value over and over, which has happened + * as a result of past CPU bugs. + * + * If it fails, it is simple to disable RDRAND and RDSEED here. */ -#define SANITY_CHECK_LOOPS 8 void x86_init_rdrand(struct cpuinfo_x86 *c) { - unsigned int changed = 0; - unsigned long tmp, prev; - int i; - - if (!cpu_has(c, X86_FEATURE_RDRAND)) - return; - - for (i = 0; i < SANITY_CHECK_LOOPS; i++) { - if (!rdrand_long(&tmp)) { - clear_cpu_cap(c, X86_FEATURE_RDRAND); - pr_warn_once("rdrand: disabled\n"); - return; + enum { SAMPLES = 8, MIN_CHANGE = 5 }; + unsigned long sample, prev; + bool failure = false; + size_t i, changed; + + if (cpu_has(c, X86_FEATURE_RDRAND)) { + for (changed = 0, i = 0; i < SAMPLES; ++i) { + if (!rdrand_long(&sample)) { + failure = true; + break; + } + changed += i && sample != prev; + prev = sample; } + if (changed < MIN_CHANGE) + failure = true; } - /* - * Stupid sanity-check whether RDRAND does *actually* generate - * some at least random-looking data. - */ - prev = tmp; - for (i = 0; i < SANITY_CHECK_LOOPS; i++) { - if (rdrand_long(&tmp)) { - if (prev != tmp) - changed++; - - prev = tmp; + if (cpu_has(c, X86_FEATURE_RDSEED)) { + for (changed = 0, i = 0; i < SAMPLES; ++i) { + if (!rdseed_long(&sample)) { + failure = true; + break; + } + changed += i && sample != prev; + prev = sample; } + if (changed < MIN_CHANGE) + failure = true; } - if (WARN_ON_ONCE(!changed)) - pr_emerg( -"RDRAND gives funky smelling output, might consider not using it by booting with \"nordrand\""); - + if (failure) { + clear_cpu_cap(c, X86_FEATURE_RDRAND); + clear_cpu_cap(c, X86_FEATURE_RDSEED); + pr_emerg("RDRAND and RDSEED are not reliable on this platform; disabling.\n"); + } } -- 2.35.1