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 58A14C4708C for ; Sat, 29 May 2021 02:40:14 +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 011F1613F5 for ; Sat, 29 May 2021 02:40:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 011F1613F5 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=tNkc6OGMJLWSlTR+aP5PYngbmRnqbJvY5CZTxNoDOKE=; b=exoPWx8gfi/981 PBq/m+SnxBUFx8Ru+8YeEeDyqE1/TB+EFWLp9mmeLA1VZA+uGa4ydD4em5FVz2+IIV/CC6dNHITLO PGuPQBqCLpU/KcDU25TI4txLi8551iSn2ur2UKHjM9PmoD+xiICVrJTQiH2V+/5XWF+33d0cN5d7l WShZB26+D2nuOyjSKiMBZGHk3QSTVwW7oz4H1RGxrT3M3Al8jqtU4DXARPdJzSmknziOQ2Nski5ET po92G3SJ7WlGxjbGh7pcy1cssTtC0Z5H0PW154Iq1/3dBiXCXQSvgBavO2eD6CuZrbEMaUr0jAbYk SPdbLV8kf9A14NTLC0eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmoqp-002hBr-BE; Sat, 29 May 2021 02:37:23 +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 1lmoqm-002h8g-05 for linux-arm-kernel@lists.infradead.org; Sat, 29 May 2021 02:37:21 +0000 Received: from ip6-localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 14T2a6Kg030778; Fri, 28 May 2021 21:36:07 -0500 Message-ID: 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 Date: Sat, 29 May 2021 12:36:06 +1000 In-Reply-To: References: <7d5697f3994fc1f9cf39d332525269056e3649b3.camel@kernel.crashing.org> <0339748b54e2faeddeec8d50e32a6c6ff4e8b3b7.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-20210528_193720_339651_993AE11E X-CRM114-Status: GOOD ( 50.56 ) 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 Fri, 2021-05-28 at 13:56 +0100, Mark Brown wrote: > On Fri, May 28, 2021 at 09:12:38AM +1000, Benjamin Herrenschmidt > wrote: > > > > 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! Hehe yup. > Note that they do both get washed through the PRNG, not that I > think it makes a huge difference to the argument here. Right. At this point, I think we can wait until HW is there and we have enough data to decide what to do with the policy. I wish the ISA was clearer in defining timing characteristics (and fail behaviour) of those instructions... as-is, we'll probably have to mess around based on whatever HW comes out, worse, possibly with quirks. > > > 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 > 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. As far as I can tell, the ISA has some pretty strict requirements for the entropy source backing RNDR, so ideally, if implementations are compliants, it *should* be a non-issue. Famous last words... :) > > > 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). > > 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. Yup. I hate this but I foresee a future where we'll have implementation quirks. I hope not but ... > > 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. Could be. I'm away from the code right now, but I would like to avoid having the system behaviour change overall based on whether it happened to hit a failure case at boot or not. For deployments at scale, that sort of "randomness" isn't the sort we want :) Cheers, Ben. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel