From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53C5CC2D0E4 for ; Fri, 20 Nov 2020 15:27:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D8EB222252 for ; Fri, 20 Nov 2020 15:27:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DU+wM10t"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="QNHSEdTF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8EB222252 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=k3h+iR78YtT5z697X6a/PgoFlCjRnHx4XkEKgizjwIw=; b=DU+wM10tyr2WwBryNyH8wr4EQ OmqyspflnNf9FibUtNg2sAcCFeo9FuvhZb2V2tHXOw0FQDlHX8/BOuD9uoEYL3lrqyIMUM3Yw4HSe vNRP87T2kh31QRKx66hXnV7ELIAAbm1Ir7fiE8EmSlIqK1Mfw5eLrP5VbUVnqWcNsDd+B3OKRWqos pW++2SVtSHCFf6ITprPvnWCnX8/xQfJUtF39RtVrIXGJ2q+I+lgRu9ehSicX0dfTNNCuz86u2cz9S tbEQaVuJMSrfJbmxaCgYa+NNyOYTF7zZTXDkDwKTGWXVnwmUrUu8DNUbScOuu5+S3vJKnr8XxWmq7 czNbSyxjQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg8Jk-0006Yx-Kw; Fri, 20 Nov 2020 15:27:20 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kg8Jh-0006Xe-EF for linux-arm-kernel@lists.infradead.org; Fri, 20 Nov 2020 15:27:18 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 769352240B; Fri, 20 Nov 2020 15:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605886036; bh=zkypNPVntse5hesjdrXLwa0zi5Eu4BcMXLccRupOcic=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QNHSEdTFBO8wQy1q4Af7SAAp0dtJLCmAoxTm5/L3gu4AwADVtUU8SmsdYcWxZ1C9v +Jq1xaflQIfNJAe2AuSUpk0FWcMwJEpddzWJsqXl9QXZVDoh9qmCLp3axXc2bgH2wt woubZobgT06zqSDAgHTQLIk4yFRYz44KkVSJVHrY= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kg8Je-00CI9B-2v; Fri, 20 Nov 2020 15:27:14 +0000 MIME-Version: 1.0 Date: Fri, 20 Nov 2020 15:27:14 +0000 From: Marc Zyngier To: Ard Biesheuvel Subject: Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness In-Reply-To: <20201105152944.16953-1-ardb@kernel.org> References: <20201105152944.16953-1-ardb@kernel.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: ardb@kernel.org, tytso@mit.edu, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, broonie@kernel.org, andre.przywara@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201120_102717_676167_E6C68658 X-CRM114-Status: GOOD ( 20.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, tytso@mit.edu, andre.przywara@arm.com, linux-kernel@vger.kernel.org, broonie@kernel.org, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-11-05 15:29, Ard Biesheuvel wrote: > 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 Looks sensible. Having this on the interrupt path looks quite heavy handed, and my understanding of the above is that it has an adverse effect on the entropy pool. Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel