Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp6049022iog; Thu, 23 Jun 2022 10:15:09 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sEtxFjUBEouk5aS8gMebrnUh7RGlQmmzL6k0ChuPljmOxW8I8qixkqGedbRhTrBZBeg8XZ X-Received: by 2002:a17:906:9b8a:b0:722:e6e0:33d with SMTP id dd10-20020a1709069b8a00b00722e6e0033dmr8838149ejc.317.1656004508986; Thu, 23 Jun 2022 10:15:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656004508; cv=none; d=google.com; s=arc-20160816; b=0bH2PkVu9fbCJc4nBjSIVfgv7gIIXNHTZ9mygosbQogNhqPnUqiWO01NpNk1y0n6Nn U9jRFQ1inO/o9ADgfmNuAOxqGeMMcuTEZ4a6lUELHudiLk+h6dMoS6LM/rx2xRg/6Qxh e8pCzcuQy6qNTUl7N4P9Gk5ThJ8p8M7x1qJaRCq66ELmPu7m2stV76UhZeoCUGIzOmkm I/Q5Dyi+jSZQ9oTOKUwkxLpZayvg9T4LFK7vtO1iGMOSe8WAyJ0+mh1EzPtpFxExmbhy J53y28tmN5J7QJIWK0nOExgzdji4Khp2pZBmxlHv86h6QvKeiDS14h2QaKPh3EkYeYW5 whEw== 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=NyX8MrXNJ/3x/JBbuztL5cJ3IDvdNLyr41vyYAuA/vc=; b=fFERTlpB1yqOYUrzO7s+9gE/bpzqo8TUdwDv0Mwzyk3sJCqTXlzeZ5Nqy/iHQ/kJCS MJa7r8kM10xhsMjeTHtX5roUY06JM3eawD4oUXtVOS1iNp7ZddsuyPCPjX8e6uTO2b0G rYkYfdjQXGVghGMqxzL8yruygoVIxs5EcYFyfvkBCwRuEp60bLpt/iPewJqL6RH63gnF deH8hqVLA/40gUD2GGgGDjayhnoYy1tiQoOl/1WWxPGceRuNuyLl5q1ESqkxocgukyQC WBC3Y9ZPhn6zSGeOoO/88LoJShF3elloaA9ZKLRdBtd9XkVV9LgIu2gE3p/hBhOyc/WT pFJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=YfG2SPbH; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v10-20020aa7d64a000000b004355a191e8csi194605edr.69.2022.06.23.10.14.41; Thu, 23 Jun 2022 10:15:08 -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=@linuxfoundation.org header.s=korg header.b=YfG2SPbH; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233703AbiFWQ6S (ORCPT + 99 others); Thu, 23 Jun 2022 12:58:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233521AbiFWQvH (ORCPT ); Thu, 23 Jun 2022 12:51:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8082A4F9E3; Thu, 23 Jun 2022 09:49:05 -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 ams.source.kernel.org (Postfix) with ESMTPS id 06585B82490; Thu, 23 Jun 2022 16:49:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 667A2C3411B; Thu, 23 Jun 2022 16:49:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656002942; bh=Zbui7v7FMbWc//788gGyBC2NlADN4nVrUFzvTcnNgOY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YfG2SPbHkeaYF/yeibqUoeOJ7ekQ8//OB5SqostMrmidFF7PPFSCGhu7Ml0hLpgo1 2lSTFSfuDK6PyJGaYp0C4582DUmFn0Rv5+sVVFMCwic9byr3tqnVIL2nX2ZtEfMhA8 ZJu64/Q5Ft3FvA4/KbAFiSfxangp3mNehC0TRsyg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ard Biesheuvel , Andre Przywara , Eric Biggers , Marc Zyngier , "Jason A. Donenfeld" , Will Deacon Subject: [PATCH 4.9 076/264] random: avoid arch_get_random_seed_long() when collecting IRQ randomness Date: Thu, 23 Jun 2022 18:41:09 +0200 Message-Id: <20220623164346.220853098@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220623164344.053938039@linuxfoundation.org> References: <20220623164344.053938039@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=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 From: Ard Biesheuvel commit 390596c9959c2a4f5b456df339f0604df3d55fe0 upstream. When reseeding the CRNG periodically, arch_get_random_seed_long() is called to obtain entropy from an architecture specific source if one is implemented. In most cases, these are special instructions, but in some cases, such as on ARM, we may want to back this using firmware calls, which are considerably more expensive. Another call to arch_get_random_seed_long() exists in the CRNG driver, in add_interrupt_randomness(), which collects entropy by capturing inter-interrupt timing and relying on interrupt jitter to provide random bits. This is done by keeping a per-CPU state, and mixing in the IRQ number, the cycle counter and the return address every time an interrupt is taken, and mixing this per-CPU state into the entropy pool every 64 invocations, or at least once per second. The entropy that is gathered this way is credited as 1 bit of entropy. Every time this happens, arch_get_random_seed_long() is invoked, and the result is mixed in as well, and also credited with 1 bit of entropy. This means that arch_get_random_seed_long() is called at least once per second on every CPU, which seems excessive, and doesn't really scale, especially in a virtualization scenario where CPUs may be oversubscribed: in cases where arch_get_random_seed_long() is backed by an instruction that actually goes back to a shared hardware entropy source (such as RNDRRS on ARM), we will end up hitting it hundreds of times per second. So let's drop the call to arch_get_random_seed_long() from add_interrupt_randomness(), and instead, rely on crng_reseed() to call the arch hook to get random seed material from the platform. Signed-off-by: Ard Biesheuvel Reviewed-by: Andre Przywara Tested-by: Andre Przywara Reviewed-by: Eric Biggers Acked-by: Marc Zyngier Reviewed-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20201105152944.16953-1-ardb@kernel.org Signed-off-by: Will Deacon Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman --- drivers/char/random.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1331,8 +1331,6 @@ void add_interrupt_randomness(int irq, i cycles_t cycles = random_get_entropy(); __u32 c_high, j_high; __u64 ip; - unsigned long seed; - int credit = 0; if (cycles == 0) cycles = get_reg(fast_pool, regs); @@ -1368,23 +1366,12 @@ void add_interrupt_randomness(int irq, i fast_pool->last = now; __mix_pool_bytes(r, &fast_pool->pool, sizeof(fast_pool->pool)); - - /* - * If we have architectural seed generator, produce a seed and - * add it to the pool. For the sake of paranoia don't let the - * architectural seed generator dominate the input from the - * interrupt noise. - */ - if (arch_get_random_seed_long(&seed)) { - __mix_pool_bytes(r, &seed, sizeof(seed)); - credit = 1; - } spin_unlock(&r->lock); fast_pool->count = 0; /* award one bit for the contents of the fast pool */ - credit_entropy_bits(r, credit + 1); + credit_entropy_bits(r, 1); } EXPORT_SYMBOL_GPL(add_interrupt_randomness);