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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 80B80C33CB1 for ; Wed, 15 Jan 2020 10:11:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4CFAC206D7 for ; Wed, 15 Jan 2020 10:11:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OIUXT0ML" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CFAC206D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FsT9cOaGCLYUc0hOoF6NoCauAUbqnNK59gqgq5EvSXI=; b=OIUXT0MLqc6d6h blfebtWTsAptjd0SLS4j8jWWSfqY/ZzrMBBoCNWPEKfGInfIAruXSuMfH2vQOUZX71sw9MhekOBxM 0BNM4W3Jxz6aXhzRYMdgyT95Qi7plWgZ5lq6EXqDcZT8+u+HYcehapSgOrQbEqEKZh0vIEgKAelll gLSL+RgTJnnwI1Q3Jqx/Wlge4pwSrcMIpkM4gcz892Eo/HzXSWUoN/i51PKWVSk0NxMboj2/QCre1 xAdJz9e2Axe1/hcnEtOFCHs28F5yzagpLrNCbNnKQtyZ15d/e9v0CnwgeH3cCy1AegD9atY2JuzZc EzwNZ9zVJTX9EL56cqEw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1irfe8-0007Xb-9a; Wed, 15 Jan 2020 10:11:32 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1irfe2-0007Ww-7w for linux-arm-kernel@lists.infradead.org; Wed, 15 Jan 2020 10:11:30 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0DFB231B; Wed, 15 Jan 2020 02:11:25 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 27EE83F6C4; Wed, 15 Jan 2020 02:11:24 -0800 (PST) Date: Wed, 15 Jan 2020 10:11:08 +0000 From: Mark Rutland To: Ard Biesheuvel Subject: Re: [PATCH v10 2/3] arm64: random: Add data to pool from setup_arch() Message-ID: <20200115101107.GA32549@lakrids.cambridge.arm.com> References: <20200110122341.8445-1-broonie@kernel.org> <20200110122341.8445-3-broonie@kernel.org> <20200115091615.GA21692@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200115_021126_322096_949C506F X-CRM114-Status: GOOD ( 24.63 ) 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: Catalin Marinas , Richard Henderson , Mark Brown , Will Deacon , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 15, 2020 at 10:22:03AM +0100, Ard Biesheuvel wrote: > On Wed, 15 Jan 2020 at 10:16, Will Deacon wrote: > > > > On Wed, Jan 15, 2020 at 08:48:46AM +0100, Ard Biesheuvel wrote: > > > On Fri, 10 Jan 2020 at 13:23, Mark Brown wrote: > > > > > > > > Since the arm64 ARCH_RANDOM implementation is not available until > > > > cpufeature has determined the system capabilities it can't be used by > > > > the generic random code to initialize the entropy pool for early use. > > > > Instead explicitly add some data to the pool from setup_arch() if the > > > > boot CPU supports v8.5-RNG, this is the point recommended by the generic > > > > code. > > > > > > > > Note that we are only adding data here, it will be mixed into the pool > > > > but won't be credited as entropy. There are currently no suitable > > > > interfaces for that at present - extending the random code to provide > > > > those will be done as a future step. Providing data is better than not > > > > doing so as it will still provide an increase in variation in the output > > > > from the random code and there will be no impact on the rate at which > > > > entropy is credited compared to what we have without this patch. > > > > > > > > > > This is slightly unfortunate, as this way, we lose the ability to use > > > random.trust_cpu=1 to get the entropy credited and initialize CRNG > > > early. > > > > Agreed. Do you think we should wait for that support before merging the > > series? Given that I don't know of any CPUs implementing this extension, > > we can probably afford not to rush this in. > > In a previous iteration, we did have a functional > arch_get_random_seed_long() early on, which would solve this issue > without even needing a patch like this. > > Perhaps Mark (Rutland) can give a recap of his concerns at the time? It meant that the common runtime path had code that was only ever meant to run at boot time, and would also run on secondary CPUs until we finalized the caps, so they'd behave inconsistently across boot and hotplug paths. I was concerned that this was messy and would be painful to reason about and debug. My suggestion was that we either: (a) Had the arch code explicitly inject the entropy in the primary setup path, as these patches do, or; (b) Had a new callback (e.g. __early_arch_get_random_seed_long()) that the core random code only called during its initialization, separate to the runtime paths. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel