Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2436297ioo; Sat, 28 May 2022 13:37:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDBXn/Vry6SYXZmqk0iYFBuC/XnJigre/kW9sNjFYb435sFUS9AvA+9uEBkzGWNVJyKnHT X-Received: by 2002:a63:2b02:0:b0:3fb:fe88:8a8f with SMTP id r2-20020a632b02000000b003fbfe888a8fmr144448pgr.247.1653770269942; Sat, 28 May 2022 13:37:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653770269; cv=none; d=google.com; s=arc-20160816; b=G5VIjig++Mss6EFPTKeLdDKCfN+BECIjaWEx3D3zvhhHMpgcuFsF2/natbqBMWu+iv 63R9VpW7ZBfkSN09tZEjDlOtzHaxCRZmyaQoz0jJeVyJOaArKmmZnt2EW8dEkGiJTeQY gDYexNe0ip6rFs3QzkpsWtYtJGDax5mNfsWYtj8/y4XlOSnCzozIJ5UzEQXHgJyCVmYU GZTdPge+0yZ5gvE9XJiepXFjW+xSrPAJpWFQRvtT0apFI78ti1KYIqjYy/B43SfW3oAO vGH2xUq0ew8dGoyiwX90dVDD3/ZA+zkwz+Rm1U/O6pTacCO2/dSEj6/9ZDKpyAEWNV3q pfFw== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=oHidi91rHJUn4vgZPxBrpY5BjmYtYXbFdI9ROsv9btY=; b=z6r/R1WHWHVY2S/gGZO4ByVehRwTImhio9Uv/HPJL5NctSfwmXIrBBjEj8wnivK8Gi EtO7GNBvgn7cE1cVIbV3htlT9r/nxIJBxQI9PMzlUcjKnlAcqLXRGRXpa1UvKJpu1WKV vl4KAlC3JXtMAkTW4toDtuRoHfaR48ZQGMm1VNiVSYzyoboKEhfRhLjq8/FAN+CYGksI dArY13aeXCNfeo4LA3U6btQqOnvO6DApbBXwpAX327Wdv1Uzp7ZXnUb7oiIpZMTSPm2h Jjri8eMrKtKSZmEpIHz0/RQ69im/WbuI5PjxRJZ5Qz+BsLWmSwAGGxU3G+mrS5eZ2GB6 gdhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="pinZ29/u"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id b14-20020a170902d50e00b0015d52457704si11410584plg.475.2022.05.28.13.37.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 13:37:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="pinZ29/u"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 72D2112D1D2; Sat, 28 May 2022 12:40:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351642AbiE0LnH (ORCPT + 99 others); Fri, 27 May 2022 07:43:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351660AbiE0Llg (ORCPT ); Fri, 27 May 2022 07:41:36 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CD13132A22; Fri, 27 May 2022 04:40:08 -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 EDA1361CDB; Fri, 27 May 2022 11:40:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 011FCC385A9; Fri, 27 May 2022 11:40:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1653651607; bh=MDm/pljiyWy7z5p2QamWBTY2xuk1WtPtJ+TRVpkiheA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pinZ29/uO3IJJhNcJE47Op+svW6/Owhj/JIqJ/SVOOQ3rIlfaMB9soGo/HPE7sstM kPX3bSEmg7IR1siwuSamsa6WTJZ0steAZDMsIgpgeQX3BcLXCWk2WqCsizCdKr5FDY e21Z2B1u8oy4gq6fdPvfHCOuC8quYeD1gz/aDybs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Theodore Tso , Eric Biggers , "Jason A. Donenfeld" Subject: [PATCH 5.17 054/111] random: reseed more often immediately after booting Date: Fri, 27 May 2022 10:49:26 +0200 Message-Id: <20220527084827.112732987@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220527084819.133490171@linuxfoundation.org> References: <20220527084819.133490171@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 From: "Jason A. Donenfeld" commit 7a7ff644aeaf071d433caffb3b8ea57354b55bd3 upstream. In order to chip away at the "premature first" problem, we augment our existing entropy accounting with more frequent reseedings at boot. The idea is that at boot, we're getting entropy from various places, and we're not very sure which of early boot entropy is good and which isn't. Even when we're crediting the entropy, we're still not totally certain that it's any good. Since boot is the one time (aside from a compromise) that we have zero entropy, it's important that we shepherd entropy into the crng fairly often. At the same time, we don't want a "premature next" problem, whereby an attacker can brute force individual bits of added entropy. In lieu of going full-on Fortuna (for now), we can pick a simpler strategy of just reseeding more often during the first 5 minutes after boot. This is still bounded by the 256-bit entropy credit requirement, so we'll skip a reseeding if we haven't reached that, but in case entropy /is/ coming in, this ensures that it makes its way into the crng rather rapidly during these early stages. Ordinarily we reseed if the previous reseeding is 300 seconds old. This commit changes things so that for the first 600 seconds of boot time, we reseed if the previous reseeding is uptime / 2 seconds old. That means that we'll reseed at the very least double the uptime of the previous reseeding. Cc: Theodore Ts'o Reviewed-by: Eric Biggers Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman --- drivers/char/random.c | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -336,6 +336,28 @@ static void crng_fast_key_erasure(u8 key } /* + * Return whether the crng seed is considered to be sufficiently + * old that a reseeding might be attempted. This happens if the last + * reseeding was CRNG_RESEED_INTERVAL ago, or during early boot, at + * an interval proportional to the uptime. + */ +static bool crng_has_old_seed(void) +{ + static bool early_boot = true; + unsigned long interval = CRNG_RESEED_INTERVAL; + + if (unlikely(READ_ONCE(early_boot))) { + time64_t uptime = ktime_get_seconds(); + if (uptime >= CRNG_RESEED_INTERVAL / HZ * 2) + WRITE_ONCE(early_boot, false); + else + interval = max_t(unsigned int, 5 * HZ, + (unsigned int)uptime / 2 * HZ); + } + return time_after(jiffies, READ_ONCE(base_crng.birth) + interval); +} + +/* * This function returns a ChaCha state that you may use for generating * random data. It also returns up to 32 bytes on its own of random data * that may be used; random_data_len may not be greater than 32. @@ -368,10 +390,10 @@ static void crng_make_state(u32 chacha_s } /* - * If the base_crng is more than 5 minutes old, we reseed, which - * in turn bumps the generation counter that we check below. + * If the base_crng is old enough, we try to reseed, which in turn + * bumps the generation counter that we check below. */ - if (unlikely(time_after(jiffies, READ_ONCE(base_crng.birth) + CRNG_RESEED_INTERVAL))) + if (unlikely(crng_has_old_seed())) crng_reseed(); local_lock_irqsave(&crngs.lock, flags);