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 A9A22C3DA49 for ; Wed, 17 Jul 2024 03:16:11 +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=Wx9wftMefKQGgxd4tgye4KZ94L9HNLNj4qERF5WWHdU=; b=spqvPTM/GUR6ECRRdP5jqN6haf XIGdbnMfiMKqeHTcOtpBT4/mpbXMl5U0HWG7zDUD6Ygsf9+5QWfYuy/kq/lRBR40Mem9evYnevzqc 2B9HAbD1MQ/fOW0gmUiruAzjVqf6Eii/KI4FgP8/qF9yURR0yvMJ7QI3n+8u4hZ3qaS+Rmz19dMu7 YyvElygzB1eoOrlvUR8LGMSvlCPngp3U8bAj0yV5n0VOZyA41SFPHbA1t5psJLfoeoCqCS34f36So B1kq3Jutq32/SdEaV/4sSxZrQhMjDsDpi5bJsl7aKpHv9QsawYAsZ6GCbcZedpu0ErTPNG56dT3tT qXmCD9mg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sTv8z-0000000CTEZ-1KPK; Wed, 17 Jul 2024 03:15:53 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sTv8e-0000000CT5Y-0TWi; Wed, 17 Jul 2024 03:15:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version: Sender:Reply-To:Content-ID:Content-Description; bh=Wx9wftMefKQGgxd4tgye4KZ94L9HNLNj4qERF5WWHdU=; b=EoI+jTLvOocjwqkRtXvH9M2UAi kOcQQBbCj48uzweJWHiCBHisnAe/ZzknVRPnI3Ceu15Ij/jH3pJ31VO7TZvAgJvTGkv9br0VgclzK kLmauSRGVgicO9de19RqzYOuuXQ/83HZUffYeLqTEuGpwmeQn/zfvY46ZT/Vn1pnxAnpmyzJetXf1 y27Gtp5CADvdemzC3QpVSwmPYLCyFBGhBf16m6aBdJDOVOP3si6A4WHMIEmmjlxwkxKVwFrAXB5ih yQa2QTfAqwgTsVltnLhPzhc2tTGjd56ag7JgZ84+hooo8DxuWa7aZOccZIvMCAgnx5G28v7hrV903 brNF2m2Q==; Received: from mail.manjaro.org ([2a01:4f8:c0c:51f3::1]) by desiato.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sTv8a-00000002CZN-0hq4; Wed, 17 Jul 2024 03:15:30 +0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1721186116; 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=Wx9wftMefKQGgxd4tgye4KZ94L9HNLNj4qERF5WWHdU=; b=m3KqP9U7ME7JQrwhR69D0rTanEjTBHOGgHUQNTwM+bth7qXiLW2WNT2fjKncXPMKnuYUk9 bkMpRl4db/D8PL/PRoAv4Jqhr/t3E3cgBAeMBFgOpVf+rr1PwGN9cV59G1LSvPUBEYVoNK d/05KWxnJzVl4YQb3ftPjF99qSBtrnaTR0jUWzY3Iy+ZW1Q4UajL3qKGQ/KG+MSLW9QGvV W0ITpQfA2ujelg9r2MfhfWoC5TAVsYgYlcQ8pC/OaY0Nlq7q8ThqiCW55hLegIkcEkDQQH JW/LSu6xHcoEaWam2yHKNjyQ+650b7qgl5j0OqiX+s4BGRUCkhQNzwzR+nkcLg== Date: Wed, 17 Jul 2024 05:14:22 +0200 From: Dragan Simic To: Daniel Golle Cc: Diederik de Haas , Chen-Yu Tsai , 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: References: <3190961.CRkYR5qTbq@bagend> <3220752.Q7WYUMVHaa@bagend> Message-ID: X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 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_041528_464839_407B60BF X-CRM114-Status: GOOD ( 22.12 ) 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 Daniel, On 2024-07-17 04:24, 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/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+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. Please note that Chen-Yu ran the tests on a board based on the RK3568, while Diederik ran the tests on boards based on the RK3566. The observed difference in the test results suggests that something differs betwen these two SoC variants, instead of having the actual boards contributing something to the whole thing. In other words, I think that enabling the HWRNG on per-board basis isn't the right thing to do, but it should be enabled on per-SoC basis, after enough testing is performed on the particular SoC. The same applies to defining any HWRNG properties in the DT. If we really had to enable the HWRNG on per-board basis, that would mean that some issues exist for certain SoC batches, affecting some boards. AFAIK, the actual board design can't affect the operation of the HWRNG, so any HWRNG issues associated with some boards can have their SoCs as the only root cause. Consequently, if any board experiences issues, we should discard its SoC as having unreliable HWRNG, because another sample of the same board, or a sample of some other board based on the same SoC, may or may not experience the same issues. I hope all this makes sense. > 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