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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 CAF89C47089 for ; Thu, 27 May 2021 23:15:39 +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 8146E613BF for ; Thu, 27 May 2021 23:15:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8146E613BF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lIz3odDqhTp1r1n3INhszH+SaegkXTGaWQCyWK/IIc8=; b=a8Js8Nz1jIDeza b1rP0Ubw6EKryVoUOu5TAABJ5cA8gL1V0QL6ZpB1lxPGSoCl0iQVFPK5jS7HHH5iE60fSLWYLicWC 1hQe5iDcccrx2C5NMpQhY0e8XZjgE5bhzVSsMPa5p/OwRp/+4KSZqCgTKk7A1AekJrOE3FQI8QZ+q QB7bpXCZA/vpdlvCojWvy2iBE7ISvo2bPkdHYf9GqXOeH38Jdpx3X+2pJ40z7Xi/Yk6PviYr1U7Bn YGaX4+UdQLkH4ms2KAzLiX4O9VnbQxo9V25rmigDBE5CoKbb5rMgYTEpMbCVboo9mrB2YrSvN7/gX JMib49HWCyqopg1Yhhkg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmPCQ-00AAno-I9; Thu, 27 May 2021 23:13:58 +0000 Received: from gate.crashing.org ([63.228.1.57]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmPCL-00AAmG-OE for linux-arm-kernel@lists.infradead.org; Thu, 27 May 2021 23:13:55 +0000 Received: from ip6-localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 14RNCctO019377; Thu, 27 May 2021 18:12:39 -0500 Message-ID: <0339748b54e2faeddeec8d50e32a6c6ff4e8b3b7.camel@kernel.crashing.org> Subject: Re: RNDR/SS vs. SMCCC From: Benjamin Herrenschmidt To: Mark Brown Cc: Andre Przywara , Will Deacon , "Saidi, Ali" , linux-arm-kernel@lists.infradead.org, benh@amazon.com Date: Fri, 28 May 2021 09:12:38 +1000 In-Reply-To: References: <7d5697f3994fc1f9cf39d332525269056e3649b3.camel@kernel.crashing.org> User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210527_161354_057814_51DE30AE X-CRM114-Status: GOOD ( 29.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2021-05-27 at 13:50 +0100, Mark Brown wrote: > On Thu, May 27, 2021 at 09:54:03AM +1000, Benjamin Herrenschmidt > wrote: Hi Mark ! > > Like the comments say the arm64 RNDR register is not intended to > be directly providing entropy but rather returning the output of > a DRBG which is seeded from an actual entropy source whereas the > SMCCC call is intended to return something from an actual entropy > source directly. Right, I was thinking about using RNDRSS instead. > The thinking was that the latter is more in > line with what the callers are expecting for the _seed variants, > it's kind of unclear what the performance/quality tradeoff is > supposed to be though. > > See the thread at > > https://lore.kernel.org/r/CAKv+Gu8y4zwpesytU7vffSCuq8YAjWcHwFHwa_LhTW_cLiSfQw@mail.gmail.com > > for discussion of the use of RNDR rather than RNDRRS - the main > concern was the potential for issues with excessive use of > entropy especially on bigger systems, possibly amplified if > there's lots of VMs, though in the meantime the random.c code got > updated to read seeds a lot less often (390596c9959c2a4f5b4 > "random: avoid arch_get_random_seed_long() when collecting IRQ > randomness") so the considerations have changed a bit since the > original discussion and we could probably already revisit that > one already. Right. It's also a lot of assumptions without data on what the actual implementations can do but I suppose there was no much choice here :-) > > Also, why not implement arch_get_random_* using RNDR rather than > > forcing these through the kernel CNRG ? > > That was the same consideration with potential issues due to > excessive usage, it was dropped at the same time as switching to > RNDR for the _seed variants. > > This was all before I started looking at the series but my > understanding is that the general idea was to go for a > conservative implementation initially and then reevaluate once > we've got actual systems and can measure how things perform in > practice. > > In practice most of the non-seed arch_get_random usage is either > a fallback if there's no seed variant or mixed in with the CRNG > output anyway. Right but I still don't believe the end result makes a whole lot of sense. In absence of SMCCC we end up using RNDR as a seed which hits the "not a great match" comment. Not a huge deal I suppose, for our (EC2) case, we could just not implement the SMCCC call, and let it use RNDR, it's still going to be better than no HW random source, I just don't like those firmware calls much. > The arch_get_random_ interfaces already provide a return code > which the callers can handle as needed, they can do something > appropriate for the scenario rather than the architecture code > having to pick. Sometimes that's to retry later (random.c does > this when seeding for example), sometimes that's to just carry on > with whatever other entropy they've already got. Ok. It's unfortunate that the ISA is so vague on the circumstances where the instructions are allowed to fail... it says "a reasonable amount of time", it may as well have said a "random amount of time" for the usefulness of it ;-) The implementation I'm aware of will fail extremely rarely when the HW detects an issues that requires corrective action, but I could imagine some implemetations just failing when there's no entropy at hand (esp. with RNDRSS). As long as the callers don't give up permanently, that's fine. I was just a bit concerned by cnrg_init_try_arch{_early}. It would be preferable for these to "try harder". Cheers, Ben. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel