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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 03A1EC433F5 for ; Thu, 13 Jan 2022 13:50:55 +0000 (UTC) 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TnI8Y2zwBLelg4pw+nhd/xpmRWwayNZXpMs4y2TLYcs=; b=fpl9rpF/4zGXAR UVHk3SWzA2UxrRSl+LKBnv08z72nPL4N7Av+mL18V6AtWVuiy4hQz0KnXdCmN2XUZkWmUQIkxq7BR B+mVETw0yMh1AZEMNG3TQBwQ+x5VCT6DEur+WJvK60ERp7IxJ14Dzy04gymFzu1xs3iv7JsgrPGSB 8srlXQ2rLkX40BOFfWounrzo27PBTe0EnAkebA1Ps50Gku8QYu7hMDIuCeV4bBs0X0tnBtCCf4/Ep Rpc+r3ayEKsfLIItwwizSZ5BZtrSNqDp/YHZpwYAltH5U7HzxM9GCIN4vcX6947Y5Dv/60sNODedh Z8/aBzkqF9/AEZXjxWOg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n80Tx-006Arw-7H; Thu, 13 Jan 2022 13:49:37 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n80Tr-006Aqt-0j for linux-arm-kernel@lists.infradead.org; Thu, 13 Jan 2022 13:49:35 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BB80CB821C7 for ; Thu, 13 Jan 2022 13:49:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D490C36AE3 for ; Thu, 13 Jan 2022 13:49:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642081768; bh=wmUnySOKhYbv2osqB1rsuiF/6+oUshmtStZy2D2E+ww=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=A0B/HgtplE1DOucHMDFoATZNT0ichupKuDZJpM9IIWGxvX+bSamsDpRTuU1Xg80Cr e/bdF+w8lZ/aAlnkCpaYdXPG/weycx8p/2XPVes5F5N74EOlfsd37uQK8EvJHT6Zc5 XXDvzznln2TVi5EVEBqDvz6HB9Tg76wpqOqDbCTlfuFvhnXGcLdUAHxfjHbCjDJD64 ZCRaxx9OCRd4/1bALwLSySUfzjVX2VoWGLVRbrtDUubedvIhF/SesKX7mVguHFdXik sjhmJHqlvuInjL99iKlQN4wXB3gtWwfcca7Z//AndhFRe932RfjymnWvfqu3KugngG SW48NHlY8b36A== Received: by mail-wr1-f50.google.com with SMTP id t20so2730519wrb.4 for ; Thu, 13 Jan 2022 05:49:28 -0800 (PST) X-Gm-Message-State: AOAM532Y4QEzIwIoSirZMVdXX/gW2q4L86MOBnk9Sm+QDCsUvvyItAX5 XgfURPo3S8nnmf59oQB0qXaQJO8JCK6lDbwTD3U= X-Google-Smtp-Source: ABdhPJyNzFA4C9KVO0Ey8sWhM+lLepQ4dMixAeCDFLx6alXt05pcV73BvSU1iMYdamPFSKy686u59eIyFBG2B4ksiQQ= X-Received: by 2002:adf:f287:: with SMTP id k7mr4162404wro.417.1642081766833; Thu, 13 Jan 2022 05:49:26 -0800 (PST) MIME-Version: 1.0 References: <20220113131239.1610455-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Thu, 13 Jan 2022 14:49:15 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] arm64: random: implement arch_get_random_int/_long based on RNDR To: "Jason A. Donenfeld" Cc: Linux ARM , Catalin Marinas , Will Deacon , Mark Rutland , Andre Przywara , Mark Brown X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220113_054931_363392_9D2400A4 X-CRM114-Status: GOOD ( 37.19 ) 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, 13 Jan 2022 at 14:41, Jason A. Donenfeld wrote: > > Hi Ard, > > Wow, didn't expect for this to come so fast. Excellent. > > On Thu, Jan 13, 2022 at 02:12:39PM +0100, Ard Biesheuvel wrote: > > - map arch_get_random_int/_long() onto RNDR, which returns the output of > > a DRBG that is reseeded at an implemented defined rate; > > implemented -> implementation? > Ack > > static inline bool __must_check arch_get_random_long(unsigned long *v) > > { > > + /* > > + * Only support the generic interface after we have detected > > + * the system wide capability, avoiding complexity with the > > + * cpufeature code and with potential scheduling between CPUs > > + * with and without the feature. > > + */ > > + if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v)) > > + return true; > > return false; > > } > > Can't this just become: > > return cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v); > Sure, but I just retained the original style. > > > > static inline bool __must_check arch_get_random_int(unsigned int *v) > > { > > + if (cpus_have_const_cap(ARM64_HAS_RNG)) { > > + unsigned long val; > > + > > + if (__arm64_rndr(&val)) { > > + *v = val; > > + return true; > > + } > > + } > > return false; > > } > > Why not implement arch_get_random_int with the same type of flow as > arch_get_random_long? > > static inline bool __must_check arch_get_random_int(unsigned int *v) > { > unsigned long val; > if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(&val))) { > *v = val; > return true; > } > return false; > } > > Or, even better, just define arch_get_random_int in terms of > arch_get_random_long: > > static inline bool __must_check arch_get_random_int(unsigned int *v) > { > unsigned long val; > if (arch_get_random_long(&val)) { > *v = val; > return true; > } > return false; > } > > If I was interested in rewriting this header file, I might consider all these options. For now, I am just trying to focus the change on the parts that actually matter. > > @@ -71,12 +105,11 @@ static inline bool __must_check arch_get_random_seed_long(unsigned long *v) > > } > > > > /* > > - * Only support the generic interface after we have detected > > - * the system wide capability, avoiding complexity with the > > - * cpufeature code and with potential scheduling between CPUs > > - * with and without the feature. > > + * RNDRRS is not backed by an entropy source but by a DRBG that is > > + * reseeded after each invocation. This is not a 100% fit but good > > + * enough to implement this API if no other entropy source exists. > > The docs are actually a bit more optimistic than that: > > https://developer.arm.com/documentation/ddi0595/2021-03/AArch64-Registers/RNDRRS--Reseeded-Random-Number > > ~ Reseeded Random Number. Returns a 64-bit random number which is reseeded > ~ from the True Random Number source immediately before the read of the > ~ random number. > > If I'm reading that correctly, it looks like the reseeding happens > *before* the read, and it looks like it comes from a TRNG. In > other words, it sounds to me like it's just doing something like > HASH(READ_TRNG()). That would be pretty darn good. > No it does not. RNDR and RNDRRS both return the output of a DRBG, the only difference is the reseed interval. Specifically, this means that, even though the ARM ARM references NIST SP800-90B directly, the RNDRRS construction is a black box containing a entropy source + DRBG, and so we shouldn't pretend that RNDRRS itself can be treated as a source of true entropy. This is especially relevant when it comes to seeding a DRBG of a certain security strength N >= the security strength of the hidden DRBG, as concatenating multiple RNDRRS results does not satisfy the requirements for seeding a DRBG of security strength N. > > */ > > - if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v)) > > + if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndrrs(v)) > > return true; > > > > return false; > > @@ -96,7 +129,7 @@ static inline bool __must_check arch_get_random_seed_int(unsigned int *v) > > } > > > > if (cpus_have_const_cap(ARM64_HAS_RNG)) { > > - if (__arm64_rndr(&val)) { > > + if (__arm64_rndrrs(&val)) { > > *v = val; > > return true; > > } > > I suppose the same control flow simplification stuff mentioned above > could be done here too, if you feel like what I mentioned earlier is > worthwhile. > > From a randomness perspective: > > Acked-by: Jason A. Donenfeld > Thanks, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel