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.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 2B767C4707F for ; Thu, 27 May 2021 12:52:43 +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 E635B6109F for ; Thu, 27 May 2021 12:52:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E635B6109F 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=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Qa4xrXPRj6MsYXnuaHhFlMzamz83HgbN4OLmMVBMSEM=; b=l5puUha7u7tiaUBwdT1d8/ctJH U/U8FOolD8CvISr3CDNDKqrZtVSkReF/V57GGk6LpB/2tKfGW+5OThcXATWtrQNvmmyf0VwWHRNx1 Ph5LHNMkXOJmqFc9c7JDLFOGbSLck4iuwDWKNOop6XGGu3/MU7yIuQWdYNQNT79RWI5YWULO8BkLL VTfUuU1a34lKmhlOYvURadk/lB6Abz2QPaPGBYsTdKMFDu5Vs82+4dAjyRf1hO+MoJaSYKhY0Ez4P Y+n7ZQzBeDCwG6VBO0/a9YUO13MlbLFaJnpnSbBCA0+SiKIEW7YPK0AtFA756kntab4KivSmg9wKW oqJonukg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmFTO-005t0J-Um; Thu, 27 May 2021 12:50:51 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmFTM-005sz6-3S for linux-arm-kernel@bombadil.infradead.org; Thu, 27 May 2021 12:50:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=IGZJZ6E6qdB2Kohb8/lDPf8t0u/dwy1b2QR/huj/byc=; b=bFHzhH8fCbdUmWQGc8IzwsZr2w fO5T4KpqncxUaE8alpNCJjedz6WbKSSD27o4BEUldq6PmIKjyeWWJ29YR/UncjBGkoS1Nyqn6SfD+ LzNl6tcdTF7Fwpb70xICvD5quqNWFJOPuXwnw0QqkfS5jWM3v6LMb9RKcpi0wb6oT5mjpWnKEoWJa h6sEH/4DBPyAdiSAs+Xwozcy5cM0GsOGovLkqdesxndw4SAiguV3bN1NdJ3CZuQB1TkQ+uB4i1BQw 9piOcCNuuY69yyeDM26gR/vOCudNOUQgnFnieryunep70S5tVUHqYVeUpcFsuVoHHf3QnV8rNvHY+ QcltliNQ==; Received: from heliosphere.sirena.org.uk ([172.104.155.198]) by casper.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lmFT6-005XKi-RA for linux-arm-kernel@lists.infradead.org; Thu, 27 May 2021 12:50:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IGZJZ6E6qdB2Kohb8/lDPf8t0u/dwy1b2QR/huj/byc=; b=b3Kt2C7IUvustbqZorgxRY6Xj5 1Bg+LKsi3BFXgcJARM4F+LaDOSyD8fjuu5VN4uoBXCM8aIZS1ia8qgQ2LIc6zoS09M9Ssi/pYwfqI xYBWCB1QFXkg/lXD3LmnHLUwm5A25pQk794oUNhS8Ex4K07H9CL2AA0j5nEbtntfExE4=; Received: from 94.196.90.140.threembb.co.uk ([94.196.90.140] helo=fitzroy.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lmFSs-006Ngr-KI; Thu, 27 May 2021 12:50:18 +0000 Received: by fitzroy.sirena.org.uk (Postfix, from userid 1000) id DB532D0EA09; Thu, 27 May 2021 13:50:16 +0100 (BST) Date: Thu, 27 May 2021 13:50:16 +0100 From: Mark Brown To: Benjamin Herrenschmidt Cc: Andre Przywara , Will Deacon , "Saidi, Ali" , benh@amazon.com, linux-arm-kernel@lists.infradead.org Subject: Re: RNDR/SS vs. SMCCC Message-ID: References: <7d5697f3994fc1f9cf39d332525269056e3649b3.camel@kernel.crashing.org> MIME-Version: 1.0 In-Reply-To: <7d5697f3994fc1f9cf39d332525269056e3649b3.camel@kernel.crashing.org> X-Cookie: A penny saved has not been spent. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210527_135036_744126_E5522205 X-CRM114-Status: GOOD ( 18.86 ) 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: multipart/mixed; boundary="===============9118641449903227700==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============9118641449903227700== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CS7Y0qY2oModBWn3" Content-Disposition: inline --CS7Y0qY2oModBWn3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 27, 2021 at 09:54:03AM +1000, Benjamin Herrenschmidt wrote: > I'm trying to understand the rationale for having SMCCC take precedence > over the architected instruction in > arch/arm64/include/asm/archrandom.h=20 > Especially I don't quite get the comment about SMCCC being more in the > "spirit" than let's say RNDRSS. It's definitely MUCH slower. 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. 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_cL= iSfQw@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. > 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. =20 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. > Finally, RNDR/RNDRSS can fail occasionally, we should probably > implement some kind of delay+retry here. I'm not super familiar with > the context in which arch_get_random_* can be called (are they allowed > to sleep ?) but from the implementation I'm aware of at least, the idea > is that they might under some HW recovery scenarii so we should sleep a > couple of ms and try again a few times. 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. --CS7Y0qY2oModBWn3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmCvlYUACgkQJNaLcl1U h9Cgqgf+NaiVIj1Q/si7/yxsfPpCL+k4V0b4cJfS8Yfe/e0hKn+UBM7gRMrvU4Kt RtrmlMacF2udrhh4/PQJdlIfMhr3THxRSmwVI03R9Ly8uGNcUUrNoe8UoI89xDmz fIIjOZhOWINKYYuKvq7QBnCRs98tXcZd1ZiFOUmaJ+cOC4SQ4tmGsrExsj12tVQP paSPg2x9kpKsoCpglnrHyjeByIpaF+hTcC+Z2wS/1BQuGkdtZF1W0dcOxcrdi/DG R59wGOvHrtPcBMnHLwGz/PURm05UCdKlhc5Vfu6avufVyKRU9qumCA+0x3Ns9jCc r/4aH5S+mjorh78f1ogLYmKSDgg3oA== =w4Hp -----END PGP SIGNATURE----- --CS7Y0qY2oModBWn3-- --===============9118641449903227700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============9118641449903227700==--