Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1287049pxu; Fri, 27 Nov 2020 04:13:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQaF2rte0xFUxg1M5qScapUwDoeFS+fpflui6SW8MuxCuk4FHRsid6yE5FRYg96CcMPEnh X-Received: by 2002:a50:d5dd:: with SMTP id g29mr7540419edj.344.1606479191468; Fri, 27 Nov 2020 04:13:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606479190; cv=none; d=google.com; s=arc-20160816; b=y424eLD+R1Rns3Am+irIcwVE20EGB7UMhf4ZPsgSfB05hJS5h1J94YkXs1wPBIJiaz ewuy4Mw12ChHzZIWqI4dZoDYEPBfbBdQomnfX9ao/1T07hjzP932vsc3HDSQlyi8TyZp 6p5oopS/otsIS9BetlVzKr9g/f7Ta3XrbPEQN+P+a5GXSpmkbsKHxKVUrdoASdvTuu65 v/IZYYiWRpnTTAmdUYg17PvHN0eNwjbFaNRMiEVumbPJQCgvKMKarnhspZPlP8TEbEMg rviCJh0KeYUvpsUfMD7FxhD3jQwnesxe1nSuz6I25fXQLWXNfqIIaJb1hDeIdfHTqXgf 3JGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=9fXLMqgIEFSwvI/jgQLvYaGAn0jqLe3WdPecwXErpQw=; b=JOpxjRiGZrbc0TRHJ8kH+kZwFirLxDvBgvgP+nuZKBWfSf5WFMw7i8N76nlR9yI22T rqjB1iLyqBNyvjLWsTcCNvIf08p2cW4rUZTknCyMHGxQz0BTyvS/l7/A5BGYF0vrxJ9t y7LQnCnI1tWk62DxNNWsTaeyL1PO8V41QDV8GwreuBo9JjX5T2g+T3mHqbcbx4trfGKh nHOPaXzgLIztQ6L0ooH5aIPDhqx/8OCZ5fcYyeTO7PKgYx9WZq5XidxExinRFv06af/n CPH73pZGWOEBSrk0Jg8Dk/Av4VhJfDo3uASjNSCxy6i1ie0NAaMKs7S0XxUZNQQALNIL l7zA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Prenpija; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l12si4940769edq.55.2020.11.27.04.12.47; Fri, 27 Nov 2020 04:13:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Prenpija; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727518AbgK0MIu (ORCPT + 99 others); Fri, 27 Nov 2020 07:08:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:36588 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725985AbgK0MIu (ORCPT ); Fri, 27 Nov 2020 07:08:50 -0500 Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 06506221F1 for ; Fri, 27 Nov 2020 12:08:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606478929; bh=9fXLMqgIEFSwvI/jgQLvYaGAn0jqLe3WdPecwXErpQw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Prenpijat5yZJ695ExkyoVG6QFbh9RwEQqYxo8ZuazTY7nit4xrFNWoJi5FKUwV4O uGbUVIELTLd2Ex4vzUWwVYmxj9/OLhRcD54o+T+GTFjj+qg3SolS9L8hsqSYgHbnFa Snjp2Q9pMjBS1Ej9HYCJcbMxl5wour3x4Ep8u7lc= Received: by mail-oi1-f178.google.com with SMTP id o25so5640836oie.5 for ; Fri, 27 Nov 2020 04:08:48 -0800 (PST) X-Gm-Message-State: AOAM53041wnwcx/7It+khNFIv7zua8sd7B8x4spUjPawAaJ0LmTiFdKK HNu3lnDW9mPNF/uRiFIRfuk1IdxVx7agVTbmSnc= X-Received: by 2002:aca:5ec2:: with SMTP id s185mr4778672oib.33.1606478928265; Fri, 27 Nov 2020 04:08:48 -0800 (PST) MIME-Version: 1.0 References: <20201105152944.16953-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Fri, 27 Nov 2020 13:08:37 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness To: Marc Zyngier , "Theodore Y. Ts'o" , Eric Biggers Cc: Linux Kernel Mailing List , Linux ARM , Mark Rutland , Mark Brown , Andre Przywara Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Nov 2020 at 16:27, Marc Zyngier wrote: > > 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 > Thanks Marc. Ted, any thoughts?