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 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 A298AC2B9F7 for ; Fri, 28 May 2021 13:15:41 +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 57D9B61183 for ; Fri, 28 May 2021 13:15:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57D9B61183 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=T9dPG+q70ot9QfFafPUBZgxg4Q32UzhN+yq1NKW6j6A=; b=GzXJ6JEeZuV3Ga0m4x9nL4c4QT 0CqwkF1c5agOJo9hzM+115SHAd7PkOG6J5OA+HTV55BOHvZfjRhHMwpfMY3lJxjzwOadAOvoPiOFK dL+dMmh4hUkdLRt8HzmyLFN6QE+wBPXGC/TC0VtEYqqvaOxTpzDx6f4kJB+Zx1WHWUt1AYgd6tyI4 W0owybzPUzA592akOp4nP1ceVB2emh6ZPghfzJPIn1cTbbio+n4ykfKsOLpdP2C+W84OUH7FpzqVq 3GScK8FqbdrcRHA/UkDIr5pALbkC4C87rvQwA9oWY5DejQ+WwTy3KQ3FTCfzufisxvSqslDrOn0FD vk/WTX+g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmcHZ-00FfpX-2J; Fri, 28 May 2021 13:12:10 +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 1lmc32-00FZ89-H3 for linux-arm-kernel@bombadil.infradead.org; Fri, 28 May 2021 12:57:08 +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=tOUVrUunyrRxCLSIPxdE1z2aDAnIFc0Mz6h+HcyO3Cs=; b=n/dOKzaSnsEQgdJ/E4ICROb3+J PqPC0Zy9gmvhpMpMeOGRXemhktvGPFSuvMTGp34/BRW+Yb1OQU7g6jgbrZNTrb/lgpmYzaX7weRsd TOwumnzeyj4VDaLLJbvN0Oc+y7loczDTcLNtkArAHr5Zhi8RhIAZNtKoCtwslWTOJIv6wnxnYx/3t EfaAzXcytRTJWWwWSX5g4dP1NHPHMlKZNXzZjSJssMTql2iGNaNvqHZ8E0u5TfrJUJr4RQnJHUgzk mUGn9sqjpxhLhkATi7S/jMX29xL68bV7UfniNf4Kdall8D43W6XtI/Y10DpUwex4N/FE0VN94FAid cfGNkWuw==; Received: from heliosphere.sirena.org.uk ([172.104.155.198]) by casper.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lmc2r-006cdB-VI for linux-arm-kernel@lists.infradead.org; Fri, 28 May 2021 12:57:01 +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=tOUVrUunyrRxCLSIPxdE1z2aDAnIFc0Mz6h+HcyO3Cs=; b=Lv6ah7YXOfMVxusdai1jolI7gk 9aV6HC7wbcy4TTeryV5z8kURV9OEOUC+8KtnF+0Xp1TCcRpso5nmoQBerLcnH1QEXgNcSn1uq7jvW qGWlDBL6uaVaI08W6xLwiSV/UrMy4sKSbJjjR/Ek/vpFtRgXjqEc/d37FEk1jjxq9dz4=; Received: from cpc102334-sgyl38-2-0-cust884.18-2.cable.virginm.net ([92.233.91.117] 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 1lmc2a-006c5j-Hz; Fri, 28 May 2021 12:56:40 +0000 Received: by fitzroy.sirena.org.uk (Postfix, from userid 1000) id 77806D0EA32; Fri, 28 May 2021 13:56:39 +0100 (BST) Date: Fri, 28 May 2021 13:56:39 +0100 From: Mark Brown To: Benjamin Herrenschmidt Cc: Andre Przywara , Will Deacon , "Saidi, Ali" , linux-arm-kernel@lists.infradead.org, benh@amazon.com Subject: Re: RNDR/SS vs. SMCCC Message-ID: References: <7d5697f3994fc1f9cf39d332525269056e3649b3.camel@kernel.crashing.org> <0339748b54e2faeddeec8d50e32a6c6ff4e8b3b7.camel@kernel.crashing.org> MIME-Version: 1.0 In-Reply-To: <0339748b54e2faeddeec8d50e32a6c6ff4e8b3b7.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-20210528_135659_805769_461BD6C0 X-CRM114-Status: GOOD ( 33.31 ) 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="===============1218600485618030112==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============1218600485618030112== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oqnVyd2HbAP6NxO6" Content-Disposition: inline --oqnVyd2HbAP6NxO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 28, 2021 at 09:12:38AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2021-05-27 at 13:50 +0100, Mark Brown wrote: > > 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. Yeah, I *suspect* that's where we'll end up longer term now that the random.c code is less enthusiastic about calling the function - it was where the patches where initially until the concerns about overloading were raised and it does seem to map more naturally onto the API. I do think we should hold off until we've got some concrete information on how real systems perform simply to avoid churn but I wouldn't be surprised to see us making changes once we have data. Sounds like you'll be able to help out here! Note that they do both get washed through the PRNG, not that I think it makes a huge difference to the argument here. > > 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. I do see them as useful for the seeding case, it shouldn't be in quite such sensitive fast paths as the regular versions and=20 it means that if a system has a better entropy source than the one backing RNDR (especially if the one backing RNDR has some actual problem) then we can override in software. As you say if the SMCCC isn't offering anything over the system registers then platforms don't need to implement it. > > 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. >=20 > 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). Yes, I think there being inadequate entropy at hand to reseed is the big concern here - some of that's going to be a quality tradeoff and it's very hard to actually enforce any constraints even if you define them so ultimately it all comes down to quality of implementation issues. > 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". Yeah, there is some scope for retries there - unfortunately the arch_get_random_ interface can't distinguish between temporary and permanent failures, and people won't want to to slow down the boot path at all by actually blocking. Looking again there's some scope for improving this process, we will continue to pull seed values in crng_reseed() but not in quite the same way. I'm now wondering if it'd make sense to hook retries of the architecture init into or alongside try_to_generate_entropy() in wait_for_random_bytes() when trust_cpu is set. --oqnVyd2HbAP6NxO6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmCw6IIACgkQJNaLcl1U h9AwLgf/fp6Nd1NohzF7h1MWvMurxPW/OTg9W/L6BdLcZX07tqVHt59X8FZY8VQT COjiCHEaKIcIX6DxVTM9XHZYmXFJikTVgyqNYH/HU3ewbaFSq5/H72LtKbUv6uCW frknjfgIfXwVFMYFE0cvJ1Qzc+MjMXIFjDIyn1QgKuzoKttYPPF24cviivW6MxO9 8IfOn66pxDvFuskL1AIZ2EYjiVt0KYLEXYpwlPBa+1s546+8MaTtuj3cV8GUlphf GQaX3a8MTzBZ2mUqN1qMfLLjfVlgluIRqG+9tLXeqGd0xjJq9DFLkr1O75gHZ8Xc vXPPw6dKWGZmNXUZuAmxbqtjy+v3KQ== =cY2h -----END PGP SIGNATURE----- --oqnVyd2HbAP6NxO6-- --===============1218600485618030112== 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 --===============1218600485618030112==--