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 2658CC3DA42 for ; Wed, 17 Jul 2024 08:32:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=djaTs/VXwkde5ykilmezCihZKxxTBjysv9dBh/bulSc=; b=LttLGUialA7WyiaZyA6b2z4tHl bdKqb6fci46kYu0sAtyC2mGg1OYz+9eDP71Q8zmAPug03OXwaYbXryFICNbB4tMTyGA4Ftht/ua6a 3IMUcL2AcjfYetTDMZN0O0eQgzbQ76T32lOPiSUY8zmfKwF/m+6glCYn9+4O8/RrAYVfo3K3RH3+S uI/uUb9A1hqC/r4MYtA64E/Pz2mMGCN0L0KB3jd3kVI8SqREMkvNGpD0DaKdhPR9+2ehBsdrF8dFz X1AQ9ozBkURa0Eencjm/IS6jfuZptKvMegkAZbTm23ySN9xwQSxQ1jHRoN0Vr65tV4MSx5toSX3Eb 6SLnSYBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sU04z-0000000D9Jp-1Zwn; Wed, 17 Jul 2024 08:32:05 +0000 Received: from mail.manjaro.org ([116.203.91.91]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sU04O-0000000D97R-1TFK; Wed, 17 Jul 2024 08:31:30 +0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1721205086; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=djaTs/VXwkde5ykilmezCihZKxxTBjysv9dBh/bulSc=; b=MA0cPLpQgynOCTGF3xZ7pX9SK2i58JLa7/0jsJS1Id8InlVCPmjxeW4Q/GMrMUNKN4gLNs 24eQupFiIzNlvEQqlN/q06ryLe6oOheQgQVibDHG5U4yBli8Gkm0dHFuJKYRpPMS7wDSwa zHLA1eJW0jrfoGoYxa3QLdY0/QxlFNqpdiMXd3zfjlocyRgLt5i8RqY1h/6t/L/K7BLfvN Ag7BNNYY/y56aqr9oeUqXxicfNvD6wZuXtawK0C2OKBlP9Z0mdLk4dAiud1T9ldnOf+htB 8G0p20FQgWUEuLsPDLYvCgJmcRbx2MD0B75xG9AaHOe0rvjns5PcLuLsCXM9MA== Date: Wed, 17 Jul 2024 10:31:22 +0200 From: Dragan Simic To: Diederik de Haas Cc: Daniel Golle , wens@kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Rob Herring , Conor Dooley , linux-kernel@vger.kernel.org, Herbert Xu , Martin Kaiser , Sascha Hauer , Sebastian Reichel , Ard Biesheuvel , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , devicetree@vger.kernel.org, linux-crypto@vger.kernel.org, Philipp Zabel , Olivia Mackall , Krzysztof Kozlowski , Aurelien Jarno , Heiko Stuebner , Anand Moon Subject: Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568 In-Reply-To: <2451882.5D0I8gZW9r@bagend> References: <2451882.5D0I8gZW9r@bagend> Message-ID: <8357f8b7a55f88186b8a222457ba5fcf@manjaro.org> X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=dsimic@manjaro.org smtp.mailfrom=dsimic@manjaro.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240717_013128_703896_B01B2D69 X-CRM114-Status: GOOD ( 32.64 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Diederik, On 2024-07-17 10:22, Diederik de Haas wrote: > On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote: >> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle >> wrote: >> > On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote: >> > > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote: >> > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0 >> > > >> > > I don't know if it means something, but I noticed that I have >> > > ``Long run: 0`` with all my poor results, >> > > while Chen-Yu had ``Long run: 1``. >> > > >> > > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their >> > > very poor result (100% failure): >> > > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6 >> > > rB2S7jg+dnoX8hAoWg@mail.gmail.com/> >> > The conclusions I draw from that rather ugly situation are: >> > - The hwrng should not be enabled by default, but it should by done >> > >> > for each board on which it is known to work well. >> > >> > - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be >> > >> > defined in DT for each board: >> > * introduce new 'rochchip,rng-sample-count' property >> > * read 'quality' property already used for timeriomem_rng >> > >> > I will prepare a follow-up patch taking those conclusions into account. >> > >> > Just for completeness, here my test result on the NanoPi R5C: >> > root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000 >> > rngtest 6.15 >> > Copyright (c) 2004 by Henrique de Moraes Holschuh >> > This is free software; see the source for copying conditions. There is NO >> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> > PURPOSE. >> > >> > rngtest: starting FIPS tests... >> > rngtest: bits received from input: 20000032 >> > rngtest: FIPS 140-2 successes: 875 >> > rngtest: FIPS 140-2 failures: 125 >> > rngtest: FIPS 140-2(2001-10-10) Monobit: 123 >> > rngtest: FIPS 140-2(2001-10-10) Poker: 5 >> > rngtest: FIPS 140-2(2001-10-10) Runs: 4 >> > rngtest: FIPS 140-2(2001-10-10) Long run: 0 >> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 >> > rngtest: input channel speed: (min=85.171; avg=141.102; >> > max=4882812.500)Kibits/s rngtest: FIPS tests speed: (min=17.809; >> > avg=19.494; max=60.169)Mibits/s rngtest: Program run time: 139628605 >> > microseconds >> >> I doubt this is per-board. The RNG is inside the SoC, so it could be a >> chip >> quality thing. > > I agree with ChenYu (and others) that this is isn't a per-board level > thing. > I'd even go further: 's/I doubt/It can't be that/' (for the same reason > though; this is inside the SoC). > > Before I saw these latest emails, I was going to suggest: > 1. Enable it only on RK3568 for now. I would be fine if this would be > accepted > by the maintainer I think we need more testing on more units of the RK3568 SoC, simply because the HWRNG may work badly on some units. I know that it sucks, but we basically need just one "bad apple" to mark an SoC as having an unreliable HWRNG, which is IMHO the only right thing to do. Of course, unless we can prove that tweaking the HWRNG knobs makes such "bad apples" work well. > 2. Ask that you make a special version (for me) where I could play with > the > params without having to compile a new kernel for each variant (it > generally > takes me more then 24h on my Q64-A). Either through kernel module > properties > or properties defined in the DeviceTree is fine with me. > > 3. Based on the results make a choice to not enable it on rk3566 at > all or > (indeed) introduce DT properties to configure it differently per SoC. See above; unfortunately, we already have some "bad RK3566 apples". > 4. Hope/Ask for more test results > >> On the RK3399 we also saw wildly varying results. > > On my Rock64('s) (RK3328) it doesn't work at all: > > ``` > root@cs21:~# cat /dev/hwrng | rngtest -c 1000 > rngtest 5 > ... > rngtest: starting FIPS tests... > cat: /dev/hwrng: No such device > rngtest: entropy source drained > ```