hwrng: add hwrng support for Rockchip RK3568

PATCH Superseded Daniel Golle 8 participants 33 messages Jul 14, 2024 – Aug 1, 2024

Subsystems (5)

Device tree bindings Crypto API Arm Rockchip Hardware random number generator core +1 more subsystems

lore

Share & tools

lore

Daniel Golle

author maintainer

2024-07-14 15:16 UTC #0 lore raw

v7 cover hwrng: add hwrng support for Rockchip RK3568

Rockchip SoCs used to have a random number generator as part of their crypto device.

However newer Rockchip SoCs like the RK3568 have an independent True Random Number Generator device. This patchset adds a driver for it and enables it in the device tree.

Tested on FriendlyARM NanoPi R5C.

v6 -> v7:
* Patch 1: unchanged

* Patch 2: bring back rk_rng_write_ctl()
- bring back rk_rng_write_ctl() with improved comment to describe the hardware.

* Patch 3: unchaned

v5 -> v6:
* Patch 1: unchanged

* Patch 2: get rid of #ifdef
- use if (IS_ENABLED(...)) { ... }instead of #ifdef inside functions
- use __maybe_unused for functions previously enclosed by #ifdef'ery

* Patch 3: unchanged

v4 -> v5:
* Patch 1: always use RK3568 name
- use full RK3568 name in patch description
- add RK3568 to title in binding

* Patch 2: full name and cosmetics
- also always mention RK3568 as there may be other RNG in other (future) Rockchip SoCs
- remove debug output on successful probe
- use MODULE_AUTHOR several times instead of single comma-separated

* Patch 3: unchanged

v3 -> v4:
* Patch 1: minor corrections
- fix Rokchip -> Rockchip typo
- change commit title as requested

* Patch 2: improved error handling and resource management
- Always use writel() instead of writel_relaxed()
- Use pm_runtime_resume_and_get
- Correctly return error code in rk_rng_read()
- Make use of devm_reset_control_array_get_exclusive
- Use devm_pm_runtime_enable and there by get rid of rk_rng_remove()

* Patch 3:
- Move node to conform with ordering by address

v2 -> v3: patch adopted by Daniel Golle
* Patch 1: address comments of Krzysztof Kozlowski, add MAINTAINERS
- improved description
- meaningful clock-names
- add entry in MAINTAINERS files

* Patch 2: numerous code-style improvements
- drop misleading rk_rng_write_ctl(), simplify I/O writes
- drop unused TRNG_RNG_DOUT_[1-7] macros
- handle error handling for pm_runtime_get_sync()
- use memcpy_fromio() instead of open coding for-loop
- some minor white-spaces fixes

* Patch 3:
- use clock-names as defined in dt-bindings

v1 -> v2:
* Patch 1: fix issues reported by Rob Herring and Krzysztof Kozlowski:
- Rename rockchip-rng.yaml into rockchip,rk3568-rng.yaml
- Fix binding title and description
- Fix compatible property
- Rename clocks and add the corresponding descriptions
- Drop reset-names
- Add a bus definition with #address-cells and #size-cells to the example.

* Patch 2: fix issue reported by kernel test robot <[email protected]>
- Do not read the random registers as big endian, looking at the RK3568 TRM this is actually not needed. This fixes a sparse warning.

* Patch 3: unchanged

Aurelien Jarno (3):
dt-bindings: rng: Add Rockchip RK3568 TRNG
hwrng: add hwrng driver for Rockchip RK3568 SoC
arm64: dts: rockchip: add DT entry for RNG to RK356x

 .../bindings/rng/rockchip,rk3568-rng.yaml     |  61 +++++
 MAINTAINERS                                   |   7 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   9 +
 drivers/char/hw_random/Kconfig                |  14 ++
 drivers/char/hw_random/Makefile               |   1 +
 drivers/char/hw_random/rockchip-rng.c         | 227 ++++++++++++++++++
 6 files changed, 319 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

Signature · 1 line

2.45.2

Daniel Golle

author maintainer

2024-07-14 15:16 UTC #1 lore raw

PATCH v7 1/3 dt-bindings: rng: Add Rockchip RK3568 TRNG

From: Aurelien Jarno <[email protected]>

Add the True Random Number Generator on the Rockchip RK3568 SoC.

Signed-off-by Aurelien Jarno <[email protected]>

Signed-off-by Daniel Golle <[email protected]>

Reviewed-by Krzysztof Kozlowski <[email protected]>

---
 .../bindings/rng/rockchip,rk3568-rng.yaml     | 61 +++++++++++++++++++
 MAINTAINERS                                   |  6 ++
 2 files changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml

Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml new file +61 -0

new file mode 100644
index 000000000000..e0595814a6d9
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/rockchip,rk3568-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3568 TRNG
+
+description: True Random Number Generator on Rockchip RK3568 SoC
+
+maintainers:
+  - Aurelien Jarno <[email protected]>
+  - Daniel Golle <[email protected]>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,rk3568-rng
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: TRNG clock
+      - description: TRNG AHB clock
+
+  clock-names:
+    items:
+      - const: core
+      - const: ahb
+
+  resets:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3568-cru.h>
+    bus {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      rng@fe388000 {
+        compatible = "rockchip,rk3568-rng";
+        reg = <0x0 0xfe388000 0x0 0x4000>;
+        clocks = <&cru CLK_TRNG_NS>, <&cru HCLK_TRNG_NS>;
+        clock-names = "core", "ahb";
+        resets = <&cru SRST_TRNG_NS>;
+      };
+    };
+
+...

MAINTAINERS +6 -0

index fb1df8c29f5a..7b2b8b1f526c 100644
@@ -19693,6 +19693,12 @@ F:	Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst
 F:	drivers/media/platform/rockchip/rkisp1
 F:	include/uapi/linux/rkisp1-config.h
 
+ROCKCHIP RK3568 RANDOM NUMBER GENERATOR SUPPORT
+M:	Daniel Golle <[email protected]>
+M:	Aurelien Jarno <[email protected]>
+S:	Maintained
+F:	Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
+
 ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
 M:	Jacob Chen <[email protected]>
 M:	Ezequiel Garcia <[email protected]>

Signature · 1 line

2.45.2

Daniel Golle

author maintainer

2024-07-14 15:16 UTC #2 lore raw

PATCH v7 2/3 hwrng: add hwrng driver for Rockchip RK3568 SoC

In reply to Daniel Golle

From: Aurelien Jarno <[email protected]>

Rockchip SoCs used to have a random number generator as part of their crypto device, and support for it has to be added to the corresponding driver. However newer Rockchip SoCs like the RK3568 have an independent True Random Number Generator device. This patch adds a driver for it, greatly inspired from the downstream driver.

The TRNG device does not seem to have a signal conditionner and the FIPS 140-2 test returns a lot of failures. They can be reduced by increasing RK_RNG_SAMPLE_CNT, in a tradeoff between quality and speed. This value has been adjusted to get ~90% of successes and the quality value has been set accordingly.

Signed-off-by Aurelien Jarno <[email protected]>

[[email protected]: code style fixes]

Signed-off-by Daniel Golle <[email protected]>

Acked-by Krzysztof Kozlowski <[email protected]>

---
 MAINTAINERS                           |   1 +
 drivers/char/hw_random/Kconfig        |  14 ++
 drivers/char/hw_random/Makefile       |   1 +
 drivers/char/hw_random/rockchip-rng.c | 227 ++++++++++++++++++++++++++
 4 files changed, 243 insertions(+)
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

MAINTAINERS +1 -0

index 7b2b8b1f526c..2745cfe56774 100644
@@ -19698,6 +19698,7 @@ M:	Daniel Golle <[email protected]>
 M:	Aurelien Jarno <[email protected]>
 S:	Maintained
 F:	Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
+F:	drivers/char/hw_random/rockchip-rng.c
 
 ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
 M:	Jacob Chen <[email protected]>

drivers/char/hw_random/Kconfig +14 -0

index 442c40efb200..2b62cd08f91a 100644
@@ -573,6 +573,20 @@ config HW_RANDOM_JH7110
 	  To compile this driver as a module, choose M here.
 	  The module will be called jh7110-trng.
 
+config HW_RANDOM_ROCKCHIP
+	tristate "Rockchip True Random Number Generator"
+	depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
+	depends on HAS_IOMEM
+	default HW_RANDOM
+	help
+	  This driver provides kernel-side support for the True Random Number
+	  Generator hardware found on some Rockchip SoC like RK3566 or RK3568.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called rockchip-rng.
+
+	  If unsure, say Y.
+
 endif # HW_RANDOM
 
 config UML_RANDOM

drivers/char/hw_random/Makefile +1 -0

index 32549a1186dc..01f012eab440 100644
@@ -48,4 +48,5 @@ obj-$(CONFIG_HW_RANDOM_XIPHERA) += xiphera-trng.o
 obj-$(CONFIG_HW_RANDOM_ARM_SMCCC_TRNG) += arm_smccc_trng.o
 obj-$(CONFIG_HW_RANDOM_CN10K) += cn10k-rng.o
 obj-$(CONFIG_HW_RANDOM_POLARFIRE_SOC) += mpfs-rng.o
+obj-$(CONFIG_HW_RANDOM_ROCKCHIP) += rockchip-rng.o
 obj-$(CONFIG_HW_RANDOM_JH7110) += jh7110-trng.o

drivers/char/hw_random/rockchip-rng.c new file +227 -0

227 lines not on this page · raw message

Signature · 1 line

2.45.2

Martin Kaiser

2024-07-15 19:49 UTC #3 lore raw

Re: [PATCH v7 2/3] hwrng: add hwrng driver for Rockchip RK3568 SoC

Hi,

Thus wrote Daniel Golle ([email protected]):

Quoted 124 lines

From: Aurelien Jarno <[email protected]>

Signed-off-by Aurelien Jarno <[email protected]>

[[email protected]: code style fixes]

Signed-off-by Daniel Golle <[email protected]>

Acked-by Krzysztof Kozlowski <[email protected]>

---
 MAINTAINERS                           |   1 +
 drivers/char/hw_random/Kconfig        |  14 ++
 drivers/char/hw_random/Makefile       |   1 +
 drivers/char/hw_random/rockchip-rng.c | 227 ++++++++++++++++++++++++++
 4 files changed, 243 insertions(+)
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

MAINTAINERS +1 -0

index 7b2b8b1f526c..2745cfe56774 100644
@@ -19698,6 +19698,7 @@ M:	Daniel Golle <[email protected]>
 M:	Aurelien Jarno <[email protected]>
 S:	Maintained
 F:	Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
+F:	drivers/char/hw_random/rockchip-rng.c
 
 ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
 M:	Jacob Chen <[email protected]>

drivers/char/hw_random/Kconfig +14 -0

index 442c40efb200..2b62cd08f91a 100644
@@ -573,6 +573,20 @@ config HW_RANDOM_JH7110
 	  To compile this driver as a module, choose M here.
 	  The module will be called jh7110-trng.
 
+config HW_RANDOM_ROCKCHIP
+	tristate "Rockchip True Random Number Generator"
+	depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
+	depends on HAS_IOMEM
+	default HW_RANDOM
+	help
+	  This driver provides kernel-side support for the True Random Number
+	  Generator hardware found on some Rockchip SoC like RK3566 or RK3568.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called rockchip-rng.
+
+	  If unsure, say Y.
+
 endif # HW_RANDOM
 
 config UML_RANDOM

drivers/char/hw_random/Makefile +1 -0

index 32549a1186dc..01f012eab440 100644
@@ -48,4 +48,5 @@ obj-$(CONFIG_HW_RANDOM_XIPHERA) += xiphera-trng.o
 obj-$(CONFIG_HW_RANDOM_ARM_SMCCC_TRNG) += arm_smccc_trng.o
 obj-$(CONFIG_HW_RANDOM_CN10K) += cn10k-rng.o
 obj-$(CONFIG_HW_RANDOM_POLARFIRE_SOC) += mpfs-rng.o
+obj-$(CONFIG_HW_RANDOM_ROCKCHIP) += rockchip-rng.o
 obj-$(CONFIG_HW_RANDOM_JH7110) += jh7110-trng.o

drivers/char/hw_random/rockchip-rng.c new file +45 -0

new file mode 100644
index 000000000000..a8ccaf14c2c2
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rockchip-rng.c True Random Number Generator driver for Rockchip RK3568 SoC
+ *
+ * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2022, Aurelien Jarno
+ * Authors:
+ *  Lin Jinhan <[email protected]>
+ *  Aurelien Jarno <[email protected]>
+ */
+#include <linux/clk.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+
+#define RK_RNG_AUTOSUSPEND_DELAY	100
+#define RK_RNG_MAX_BYTE			32
+#define RK_RNG_POLL_PERIOD_US		100
+#define RK_RNG_POLL_TIMEOUT_US		10000
+
+/*
+ * TRNG collects osc ring output bit every RK_RNG_SAMPLE_CNT time. The value is
+ * a tradeoff between speed and quality and has been adjusted to get a quality
+ * of ~900 (~90% of FIPS 140-2 successes).
+ */
+#define RK_RNG_SAMPLE_CNT		1000
+
+/* TRNG registers from RK3568 TRM-Part2, section 5.4.1 */
+#define TRNG_RST_CTL			0x0004
+#define TRNG_RNG_CTL			0x0400
+#define TRNG_RNG_CTL_LEN_64_BIT		(0x00 << 4)
+#define TRNG_RNG_CTL_LEN_128_BIT	(0x01 << 4)
+#define TRNG_RNG_CTL_LEN_192_BIT	(0x02 << 4)
+#define TRNG_RNG_CTL_LEN_256_BIT	(0x03 << 4)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_0	(0x00 << 2)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_1	(0x01 << 2)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_2	(0x02 << 2)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_3	(0x03 << 2)

drivers/char/hw_random/rockchip-rng.c line 55

Quoted 10 lines

drivers/char/hw_random/rockchip-rng.c new file +10 -0

+#define TRNG_RNG_CTL_MASK		GENMASK(15, 0)
+#define TRNG_RNG_CTL_ENABLE		BIT(1)
+#define TRNG_RNG_CTL_START		BIT(0)
+#define TRNG_RNG_SAMPLE_CNT		0x0404
+#define TRNG_RNG_DOUT			0x0410
+
+struct rk_rng {
+	struct hwrng rng;
+	void __iomem *base;
+	struct reset_control *rst;

does it make sense to store rst here? it's used only in the probe function.

Quoted 42 lines

drivers/char/hw_random/rockchip-rng.c new file +42 -0

+	int clk_num;
+	struct clk_bulk_data *clk_bulks;
+};
+
+/* The mask in the upper 16 bits determines the bits that are updated */
+static void rk_rng_write_ctl(struct rk_rng *rng, u32 val, u32 mask)
+{
+	writel((mask << 16) | val, rng->base + TRNG_RNG_CTL);
+}
+
+static int rk_rng_init(struct hwrng *rng)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+	int ret;
+
+	/* start clocks */
+	ret = clk_bulk_prepare_enable(rk_rng->clk_num, rk_rng->clk_bulks);
+	if (ret < 0) {
+		dev_err((struct device *) rk_rng->rng.priv,
+			"Failed to enable clks %d\n", ret);
+		return ret;
+	}
+
+	/* set the sample period */
+	writel(RK_RNG_SAMPLE_CNT, rk_rng->base + TRNG_RNG_SAMPLE_CNT);
+
+	/* set osc ring speed and enable it */
+	rk_rng_write_ctl(rk_rng, TRNG_RNG_CTL_LEN_256_BIT |
+				 TRNG_RNG_CTL_OSC_RING_SPEED_0 |
+				 TRNG_RNG_CTL_ENABLE,
+			 TRNG_RNG_CTL_MASK);
+
+	return 0;
+}
+
+static void rk_rng_cleanup(struct hwrng *rng)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+
+	/* stop TRNG */
+	rk_rng_write_ctl(rk_rng, 0, TRNG_RNG_CTL_MASK);
+

drivers/char/hw_random/rockchip-rng.c line 107

Quoted 10 lines

drivers/char/hw_random/rockchip-rng.c new file +10 -0

+	/* stop clocks */
+	clk_bulk_disable_unprepare(rk_rng->clk_num, rk_rng->clk_bulks);
+}
+
+static int rk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+	size_t to_read = min_t(size_t, max, RK_RNG_MAX_BYTE);
+	u32 reg;
+	int ret = 0;

no need to initialise ret, it's overwritten immediately

Quoted 56 lines

drivers/char/hw_random/rockchip-rng.c new file +56 -0

+
+	ret = pm_runtime_resume_and_get((struct device *) rk_rng->rng.priv);
+	if (ret < 0)
+		return ret;
+
+	/* Start collecting random data */
+	rk_rng_write_ctl(rk_rng, TRNG_RNG_CTL_START, TRNG_RNG_CTL_START);
+
+	ret = readl_poll_timeout(rk_rng->base + TRNG_RNG_CTL, reg,
+				 !(reg & TRNG_RNG_CTL_START),
+				 RK_RNG_POLL_PERIOD_US,
+				 RK_RNG_POLL_TIMEOUT_US);
+	if (ret < 0)
+		goto out;
+
+	/* Read random data stored in the registers */
+	memcpy_fromio(buf, rk_rng->base + TRNG_RNG_DOUT, to_read);
+out:
+	pm_runtime_mark_last_busy((struct device *) rk_rng->rng.priv);
+	pm_runtime_put_sync_autosuspend((struct device *) rk_rng->rng.priv);
+
+	return (ret < 0) ? ret : to_read;
+}
+
+static int rk_rng_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rk_rng *rk_rng;
+	int ret;
+
+	rk_rng = devm_kzalloc(dev, sizeof(*rk_rng), GFP_KERNEL);
+	if (!rk_rng)
+		return -ENOMEM;
+
+	rk_rng->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(rk_rng->base))
+		return PTR_ERR(rk_rng->base);
+
+	rk_rng->clk_num = devm_clk_bulk_get_all(dev, &rk_rng->clk_bulks);
+	if (rk_rng->clk_num < 0)
+		return dev_err_probe(dev, rk_rng->clk_num,
+				     "Failed to get clks property\n");
+
+	rk_rng->rst = devm_reset_control_array_get_exclusive(&pdev->dev);
+	if (IS_ERR(rk_rng->rst))
+		return dev_err_probe(dev, PTR_ERR(rk_rng->rst),
+				     "Failed to get reset property\n");
+
+	reset_control_assert(rk_rng->rst);
+	udelay(2);
+	reset_control_deassert(rk_rng->rst);
+
+	platform_set_drvdata(pdev, rk_rng);
+
+	rk_rng->rng.name = dev_driver_string(dev);
+	if (!IS_ENABLED(CONFIG_PM)) {

drivers/char/hw_random/rockchip-rng.c line 173

Quoted 10 lines

drivers/char/hw_random/rockchip-rng.c new file +10 -0

+		rk_rng->rng.init = rk_rng_init;
+		rk_rng->rng.cleanup = rk_rng_cleanup;
+	}
+	rk_rng->rng.read = rk_rng_read;
+	rk_rng->rng.priv = (unsigned long) dev;
+	rk_rng->rng.quality = 900;
+
+	pm_runtime_set_autosuspend_delay(dev, RK_RNG_AUTOSUSPEND_DELAY);
+	pm_runtime_use_autosuspend(dev);
+	devm_pm_runtime_enable(dev);

could this fail? is it worth checking the return value?

Quoted 56 lines

drivers/char/hw_random/rockchip-rng.c new file +54 -0

+
+	ret = devm_hwrng_register(dev, &rk_rng->rng);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "Failed to register Rockchip hwrng\n");
+
+	return 0;
+}
+
+static int __maybe_unused rk_rng_runtime_suspend(struct device *dev)
+{
+	struct rk_rng *rk_rng = dev_get_drvdata(dev);
+
+	rk_rng_cleanup(&rk_rng->rng);
+
+	return 0;
+}
+
+static int __maybe_unused rk_rng_runtime_resume(struct device *dev)
+{
+	struct rk_rng *rk_rng = dev_get_drvdata(dev);
+
+	return rk_rng_init(&rk_rng->rng);
+}
+
+static const struct dev_pm_ops rk_rng_pm_ops = {
+	SET_RUNTIME_PM_OPS(rk_rng_runtime_suspend,
+				rk_rng_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+};
+
+static const struct of_device_id rk_rng_dt_match[] = {
+	{ .compatible = "rockchip,rk3568-rng", },
+	{ /* sentinel */ },
+};
+
+MODULE_DEVICE_TABLE(of, rk_rng_dt_match);
+
+static struct platform_driver rk_rng_driver = {
+	.driver	= {
+		.name	= "rockchip-rng",
+		.pm	= &rk_rng_pm_ops,
+		.of_match_table = rk_rng_dt_match,
+	},
+	.probe	= rk_rng_probe,
+};
+
+module_platform_driver(rk_rng_driver);
+
+MODULE_DESCRIPTION("Rockchip RK3568 True Random Number Generator driver");
+MODULE_AUTHOR("Lin Jinhan <[email protected]>");
+MODULE_AUTHOR("Aurelien Jarno <[email protected]>");
+MODULE_AUTHOR("Daniel Golle <[email protected]>");
+MODULE_LICENSE("GPL");

Signature · 1 line

2.45.2

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Jason A. Donenfeld

2024-07-21 00:26 UTC #4 lore raw

Re: [PATCH v7 2/3] hwrng: add hwrng driver for Rockchip RK3568 SoC

In reply to Daniel Golle

drivers/char/hw_random/rockchip-rng.c line 169

Quoted 1 line · Daniel Golle

drivers/char/hw_random/rockchip-rng.c new file +1 -0
+	rk_rng->rng.quality = 900;

This is out of 1024, not 1000.

https://elixir.bootlin.com/linux/v6.10/source/include/linux/hw_random.h#L35

Daniel Golle

author maintainer

2024-07-14 15:18 UTC #5 lore raw

PATCH v7 3/3 arm64: dts: rockchip: add DT entry for RNG to RK356x

In reply to Daniel Golle

From: Aurelien Jarno <[email protected]>

Enable the just added Rockchip RNG driver for RK356x SoCs.

Signed-off-by Aurelien Jarno <[email protected]>

Signed-off-by Daniel Golle <[email protected]>

---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

arch/arm64/boot/dts/rockchip/rk356x.dtsi +9 -0

index 4690be841a1c..78377e7d1d6d 100644
@@ -1113,6 +1113,15 @@ sdhci: mmc@fe310000 {
 		status = "disabled";
 	};
 
+	rng: rng@fe388000 {
+		compatible = "rockchip,rk3568-rng";
+		reg = <0x0 0xfe388000 0x0 0x4000>;
+		clocks = <&cru CLK_TRNG_NS>, <&cru HCLK_TRNG_NS>;
+		clock-names = "core", "ahb";
+		resets = <&cru SRST_TRNG_NS>;
+		reset-names = "reset";
+	};
+
 	i2s0_8ch: i2s@fe400000 {
 		compatible = "rockchip,rk3568-i2s-tdm";
 		reg = <0x0 0xfe400000 0x0 0x1000>;

Signature · 1 line

2.45.2

Chen-Yu Tsai

Tested-by on the v7 series

2024-07-14 18:09 UTC #6 lore raw

In reply to Daniel Golle

Quoted 87 lines · Daniel Golle

Rockchip SoCs used to have a random number generator as part of their crypto device.
However newer Rockchip SoCs like the RK3568 have an independent True Random Number Generator device. This patchset adds a driver for it and enables it in the device tree.
Tested on FriendlyARM NanoPi R5C.
v6 -> v7:
* Patch 1: unchanged
* Patch 2: bring back rk_rng_write_ctl()
- bring back rk_rng_write_ctl() with improved comment to describe the hardware.
* Patch 3: unchaned
v5 -> v6:
* Patch 1: unchanged
* Patch 2: get rid of #ifdef
- use if (IS_ENABLED(...)) { ... }instead of #ifdef inside functions
- use __maybe_unused for functions previously enclosed by #ifdef'ery
* Patch 3: unchanged
v4 -> v5:
* Patch 1: always use RK3568 name
- use full RK3568 name in patch description
- add RK3568 to title in binding
* Patch 2: full name and cosmetics
- also always mention RK3568 as there may be other RNG in other (future) Rockchip SoCs
- remove debug output on successful probe
- use MODULE_AUTHOR several times instead of single comma-separated
* Patch 3: unchanged
v3 -> v4:
* Patch 1: minor corrections
- fix Rokchip -> Rockchip typo
- change commit title as requested
* Patch 2: improved error handling and resource management
- Always use writel() instead of writel_relaxed()
- Use pm_runtime_resume_and_get
- Correctly return error code in rk_rng_read()
- Make use of devm_reset_control_array_get_exclusive
- Use devm_pm_runtime_enable and there by get rid of rk_rng_remove()
* Patch 3:
- Move node to conform with ordering by address
v2 -> v3: patch adopted by Daniel Golle
* Patch 1: address comments of Krzysztof Kozlowski, add MAINTAINERS
- improved description
- meaningful clock-names
- add entry in MAINTAINERS files
* Patch 2: numerous code-style improvements
- drop misleading rk_rng_write_ctl(), simplify I/O writes
- drop unused TRNG_RNG_DOUT_[1-7] macros
- handle error handling for pm_runtime_get_sync()
- use memcpy_fromio() instead of open coding for-loop
- some minor white-spaces fixes
* Patch 3:
- use clock-names as defined in dt-bindings
v1 -> v2:
* Patch 1: fix issues reported by Rob Herring and Krzysztof Kozlowski:
- Rename rockchip-rng.yaml into rockchip,rk3568-rng.yaml
- Fix binding title and description
- Fix compatible property
- Rename clocks and add the corresponding descriptions
- Drop reset-names
- Add a bus definition with #address-cells and #size-cells to the example.
* Patch 2: fix issue reported by kernel test robot <[email protected]>
- Do not read the random registers as big endian, looking at the RK3568 TRM this is actually not needed. This fixes a sparse warning.

Quoted 7 lines

* Patch 3: unchanged
Aurelien Jarno (3):
dt-bindings: rng: Add Rockchip RK3568 TRNG
hwrng: add hwrng driver for Rockchip RK3568 SoC
arm64: dts: rockchip: add DT entry for RNG to RK356x

Tested-by Chen-Yu Tsai <[email protected]>

Quoted 12 lines

 .../bindings/rng/rockchip,rk3568-rng.yaml     |  61 +++++
 MAINTAINERS                                   |   7 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   9 +
 drivers/char/hw_random/Kconfig                |  14 ++
 drivers/char/hw_random/Makefile               |   1 +
 drivers/char/hw_random/rockchip-rng.c         | 227 ++++++++++++++++++
 6 files changed, 319 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

--
2.45.2

Diederik de Haas

2024-07-16 12:34 UTC #7 lore raw

In reply to Daniel Golle

Quoted 24 lines · On Sunday, 14 July 2024 17:15:35 CEST Daniel Golle wrote:

Rockchip SoCs used to have a random number generator as part of their crypto device.
However newer Rockchip SoCs like the RK3568 have an independent True Random Number Generator device. This patchset adds a driver for it and enables it in the device tree.
Tested on FriendlyARM NanoPi R5C.
...
Aurelien Jarno (3):
dt-bindings: rng: Add Rockchip RK3568 TRNG
hwrng: add hwrng driver for Rockchip RK3568 SoC
arm64: dts: rockchip: add DT entry for RNG to RK356x
 .../bindings/rng/rockchip,rk3568-rng.yaml     |  61 +++++
 MAINTAINERS                                   |   7 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   9 +
 drivers/char/hw_random/Kconfig                |  14 ++
 drivers/char/hw_random/Makefile               |   1 +
 drivers/char/hw_random/rockchip-rng.c         | 227 ++++++++++++++++++
 6 files changed, 319 insertions(+)
 create mode 100644

Quoted 2 lines

Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml create mode 100644 drivers/char/hw_random/rockchip-rng.c

I just did the following test on my Quartz64 Model A running kernel 6.10
+ a number of patches, including this one:

===============================================================

root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.64507 s, 17.7 kB/s
root@quartz64a:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 362
rngtest: FIPS 140-2 failures: 638
rngtest: FIPS 140-2(2001-10-10) Monobit: 634
rngtest: FIPS 140-2(2001-10-10) Poker: 106
rngtest: FIPS 140-2(2001-10-10) Runs: 43
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=2.638; avg=139.351; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=21.169; avg=36.158; max=68.610)Mibits/s
rngtest: Program run time: 148109761 microseconds
===============================================================

That's almost twice as many failures as successes ...

Daniel Golle

author maintainer

2024-07-16 13:28 UTC #8 lore raw

Hi Diederik,

Quoted 15 lines · Diederik de Haas

[...]
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 362
rngtest: FIPS 140-2 failures: 638
rngtest: FIPS 140-2(2001-10-10) Monobit: 634
rngtest: FIPS 140-2(2001-10-10) Poker: 106
rngtest: FIPS 140-2(2001-10-10) Runs: 43
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=2.638; avg=139.351; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=21.169; avg=36.158; max=68.610)Mibits/s
rngtest: Program run time: 148109761 microseconds
===============================================================

Quoted 1 line

That's almost twice as many failures as successes ...

That's bad news, and apparently different from Aurelien's initial testing of the driver.

Can you try if the result is also that bad when using his version of the driver:

https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/

If so, we can try to increase RK_RNG_SAMPLE_CNT, and we may need different values depending on the SoC...

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Diederik de Haas

2024-07-16 13:59 UTC #9 lore raw

Hi Daniel,

Quoted 22 lines · On Tuesday, 16 July 2024 15:27:33 CEST Daniel Golle wrote:

Quoted 16 lines · Diederik de Haas
[...]
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 362
rngtest: FIPS 140-2 failures: 638
rngtest: FIPS 140-2(2001-10-10) Monobit: 634
rngtest: FIPS 140-2(2001-10-10) Poker: 106
rngtest: FIPS 140-2(2001-10-10) Runs: 43
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=2.638; avg=139.351; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=21.169; avg=36.158; max=68.610)Mibits/s rngtest: Program run time: 148109761 microseconds
===============================================================
Quoted 1 line
That's almost twice as many failures as successes ...
That's bad news, and apparently different from Aurelien's initial testing of the driver.

Quoted 8 lines

Can you try if the result is also that bad when using his version of the driver:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20221128184718.1
[email protected]/
If so, we can try to increase RK_RNG_SAMPLE_CNT, and we may need different values depending on the SoC...

I had been using a rebased version (with fixed includes) of Aurelien's patch set and I switched to 'your' version somewhere in the 6.10-rcX cycle, but I didn't record exactly when.
But I had a 6.9.2 kernel of which I'm confident has that rebased patch set:

===========================================================

root@quartz64a:~# uname -a
Linux quartz64a 6.9+unreleased-arm64 #1 SMP Debian 6.9.2-1~cknow (2024-04-24) aarch64 GNU/Linux

root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.6801 s, 17.6 kB/s
root@quartz64a:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 361
rngtest: FIPS 140-2 failures: 639
rngtest: FIPS 140-2(2001-10-10) Monobit: 637
rngtest: FIPS 140-2(2001-10-10) Poker: 115
rngtest: FIPS 140-2(2001-10-10) Runs: 34
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=2.603; avg=137.548; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=21.479; avg=37.156; max=89.547)Mibits/s
rngtest: Program run time: 149992805 microseconds
===========================================================

So that's consistent(ly bad).

For shits and giggles, I tried it on my PineTab2 too (also rk3566):

===========================================================

root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24) aarch64 GNU/Linux

root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s

root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 730
rngtest: FIPS 140-2 failures: 270
rngtest: FIPS 140-2(2001-10-10) Monobit: 266
rngtest: FIPS 140-2(2001-10-10) Poker: 23
rngtest: FIPS 140-2(2001-10-10) Runs: 9
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=2.615; avg=137.889; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=24.643; avg=34.518; max=68.364)Mibits/s
rngtest: Program run time: 149674336 microseconds
===========================================================

That's looking quite a lot better ... and I have no idea why.

The Q64-A is used as headless server and the PineTab2 is not, but I connected to both over SSH and they were freshly booted into, thus I haven't actually/normally used the PT2 since boot.

HTH,
Diederik

Diederik de Haas

2024-07-16 14:13 UTC #10 lore raw

Quoted 34 lines · On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:

For shits and giggles, I tried it on my PineTab2 too (also rk3566):
===========================================================
root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24)
aarch64 GNU/Linux
root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 730
rngtest: FIPS 140-2 failures: 270
rngtest: FIPS 140-2(2001-10-10) Monobit: 266
rngtest: FIPS 140-2(2001-10-10) Poker: 23
rngtest: FIPS 140-2(2001-10-10) Runs: 9
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=2.615; avg=137.889; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 microseconds
===========================================================

Quoted 5 lines

That's looking quite a lot better ... and I have no idea why.
The Q64-A is used as headless server and the PineTab2 is not, but I connected to both over SSH and they were freshly booted into, thus I haven't actually/normally used the PT2 since boot.

I did freshly install rng-tools5 package before running the test, so I rebooted again to make sure that wasn't a factor:

===========================================================

root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 704
rngtest: FIPS 140-2 failures: 296
rngtest: FIPS 140-2(2001-10-10) Monobit: 293
rngtest: FIPS 140-2(2001-10-10) Poker: 32
rngtest: FIPS 140-2(2001-10-10) Runs: 10
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=2.612; avg=137.833; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s
rngtest: Program run time: 149736205 microseconds
===========================================================

So that 704/296 vs 730/270 in the previous run on the PT2.

In case it helps:
===========================================================

root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng 
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0

root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng 
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0
===========================================================

Cheers,
Diederik

Chen-Yu Tsai

2024-07-16 15:19 UTC #11 lore raw

Quoted 74 lines · Diederik de Haas

Quoted 34 lines · On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
For shits and giggles, I tried it on my PineTab2 too (also rk3566):
===========================================================
root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24)
aarch64 GNU/Linux
root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 730
rngtest: FIPS 140-2 failures: 270
rngtest: FIPS 140-2(2001-10-10) Monobit: 266
rngtest: FIPS 140-2(2001-10-10) Poker: 23
rngtest: FIPS 140-2(2001-10-10) Runs: 9
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=2.615; avg=137.889; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 microseconds
===========================================================
Quoted 5 lines
That's looking quite a lot better ... and I have no idea why.
The Q64-A is used as headless server and the PineTab2 is not, but I connected to both over SSH and they were freshly booted into, thus I haven't actually/normally used the PT2 since boot.
I did freshly install rng-tools5 package before running the test, so I rebooted again to make sure that wasn't a factor:
===========================================================
root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 704
rngtest: FIPS 140-2 failures: 296
rngtest: FIPS 140-2(2001-10-10) Monobit: 293
rngtest: FIPS 140-2(2001-10-10) Poker: 32
rngtest: FIPS 140-2(2001-10-10) Runs: 10
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=2.612; avg=137.833; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s
rngtest: Program run time: 149736205 microseconds
===========================================================
So that 704/296 vs 730/270 in the previous run on the PT2.
In case it helps:
===========================================================
root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0

Quoted 6 lines

root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0
===========================================================

On my Rock 3A:

wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 992
rngtest: FIPS 140-2 failures: 8
rngtest: FIPS 140-2(2001-10-10) Monobit: 7
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.658; avg=140.067; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=26.751; avg=34.901; max=65.320)Mibits/s
rngtest: Program run time: 147367594 microseconds

wens@rock-3a:~$ uname -a
Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux

ChenYu

Diederik de Haas

2024-07-16 16:53 UTC #12 lore raw

Quoted 105 lines · On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:

Quoted 74 lines · Diederik de Haas
Quoted 34 lines · On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
For shits and giggles, I tried it on my PineTab2 too (also rk3566):
===========================================================
root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
(2024-04-24) aarch64 GNU/Linux
root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 730
rngtest: FIPS 140-2 failures: 270
rngtest: FIPS 140-2(2001-10-10) Monobit: 266
rngtest: FIPS 140-2(2001-10-10) Poker: 23
rngtest: FIPS 140-2(2001-10-10) Runs: 9
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=2.615; avg=137.889; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 microseconds
===========================================================
Quoted 5 lines
That's looking quite a lot better ... and I have no idea why.
The Q64-A is used as headless server and the PineTab2 is not, but I connected to both over SSH and they were freshly booted into, thus I haven't actually/normally used the PT2 since boot.
I did freshly install rng-tools5 package before running the test, so I rebooted again to make sure that wasn't a factor:
===========================================================
root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 704
rngtest: FIPS 140-2 failures: 296
rngtest: FIPS 140-2(2001-10-10) Monobit: 293
rngtest: FIPS 140-2(2001-10-10) Poker: 32
rngtest: FIPS 140-2(2001-10-10) Runs: 10
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=2.612; avg=137.833; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s rngtest: Program run time: 149736205 microseconds
===========================================================
So that 704/296 vs 730/270 in the previous run on the PT2.
In case it helps:
===========================================================
root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0
Quoted 6 lines
root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0
===========================================================
On my Rock 3A:
wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 992
rngtest: FIPS 140-2 failures: 8
rngtest: FIPS 140-2(2001-10-10) Monobit: 7
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.658; avg=140.067; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=26.751; avg=34.901; max=65.320)Mibits/s rngtest: Program run time: 147367594 microseconds

Quoted 3 lines

wens@rock-3a:~$ uname -a
Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux

I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before the actual test run made a difference.
Tried it on my Quartz64 Model A: no

Then I tried it on my Quartz64 Model B:

root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 120
rngtest: FIPS 140-2 failures: 880
rngtest: FIPS 140-2(2001-10-10) Monobit: 879
rngtest: FIPS 140-2(2001-10-10) Poker: 332
rngtest: FIPS 140-2(2001-10-10) Runs: 91
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=2.615; avg=138.117; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=20.777; avg=34.535; max=68.857)Mibits/s
rngtest: Program run time: 149461754 microseconds

root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s

root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 104
rngtest: FIPS 140-2 failures: 896
rngtest: FIPS 140-2(2001-10-10) Monobit: 892
rngtest: FIPS 140-2(2001-10-10) Poker: 335
rngtest: FIPS 140-2(2001-10-10) Runs: 79
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=2.613; avg=138.098; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=20.465; avg=34.587; max=69.107)Mibits/s
rngtest: Program run time: 149475187 microseconds

root@quartz64b:~# uname -a
Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24) aarch64 GNU/Linux

:-O

Diederik de Haas

2024-07-16 17:19 UTC #13 lore raw

Quoted 1 line · 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/

Daniel Golle

author maintainer

2024-07-17 02:25 UTC #14 lore raw

Quoted 10 lines · Diederik de Haas

Quoted 1 line · 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.

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

Chen-Yu Tsai

2024-07-17 02:59 UTC #15 lore raw

Quoted 29 lines · Daniel Golle

Quoted 10 lines · Diederik de Haas
Quoted 1 line · 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.
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.

Quoted 12 lines

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. On the RK3399 we also saw wildly varying results.

ChenYu

Dragan Simic

2024-07-17 03:34 UTC #16 lore raw

Hello Chen-Yu,

Quoted 43 lines · Chen-Yu Tsai

Quoted 29 lines · Daniel Golle
Quoted 10 lines · Diederik de Haas
Quoted 1 line · 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.
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.
Quoted 12 lines
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

Quoted 2 lines

I doubt this is per-board. The RNG is inside the SoC, so it could be a chip quality thing.

Totally agreed. I see no way how a board design could affect the HWRNGs built into Rockchip SoCs. I even checked the RK3399 and RK3566 Hardware Design Guides to be extra sure.

Quoted 1 line

On the RK3399 we also saw wildly varying results.

In my opinion, that qualifies the RK3399's HWRNG as unsuitable for general use. Having a HWRNG that fails to pass the tests on _some_ units is simply not acceptable from the security standpoint.

Anand Moon

2024-07-17 05:06 UTC #17 lore raw

In reply to Chen-Yu Tsai

Hi All,

Quoted 44 lines · Chen-Yu Tsai

Quoted 29 lines · Daniel Golle
Quoted 10 lines · Diederik de Haas
Quoted 1 line · 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.
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.
Quoted 12 lines
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

Quoted 3 lines

I doubt this is per-board. The RNG is inside the SoC, so it could be a chip quality thing. On the RK3399 we also saw wildly varying results.

I feel the latest rng-tool only supports Intel platform x86_64 and i386. It has no proper support for Arm64 and Armv7
It is heavily modified for the X86 platform
so it's not suitable for testing on other platforms.

If we enable HWRNG on all the Rockchip platforms it will be better.

[1] https://github.com/nhorman/rng-tools

Quoted 1 line

ChenYu

Thanks

-Anand

Dragan Simic

2024-07-17 05:18 UTC #18 lore raw

Hello Anand,

Quoted 48 lines · Anand Moon

Quoted 44 lines · Chen-Yu Tsai
Quoted 29 lines · Daniel Golle
Quoted 10 lines · Diederik de Haas
Quoted 1 line · 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.
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.
Quoted 12 lines
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
Quoted 3 lines
I doubt this is per-board. The RNG is inside the SoC, so it could be a chip quality thing. On the RK3399 we also saw wildly varying results.

Quoted 8 lines

I feel the latest rng-tool only supports Intel platform x86_64 and i386. It has no proper support for Arm64 and Armv7
It is heavily modified for the X86 platform
so it's not suitable for testing on other platforms.
If we enable HWRNG on all the Rockchip platforms it will be better.
[1] https://github.com/nhorman/rng-tools

I don't see what could be tweaked in rngtest(1) to support any platform better than the other, and still remain a valid test. It just applies certain FIPS test(s) to the random data obtained from /dev/hwrng or some other source, and if that testing is tweaked in any way, then the test results aren't valid on any platform.

In other words, perhaps the other components of rng-tools are tweaked to support "mainstream" platforms better, but rngtest(1) simply must not be tweaked in any way.

Diederik de Haas

2024-07-17 08:22 UTC #19 lore raw

In reply to Chen-Yu Tsai

Quoted 48 lines · On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:

Quoted 33 lines · Daniel Golle
Quoted 11 lines · Diederik de Haas
Quoted 1 line · 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
[email protected]/>
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.
Quoted 13 lines
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

Quoted 2 lines

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

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.

4. Hope/Ask for more test results

Quoted 1 line

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
```

Cheers,
Diederik

Dragan Simic

2024-07-17 08:31 UTC #20 lore raw

Hello Diederik,

Quoted 52 lines · Diederik de Haas

Quoted 48 lines · On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:
Quoted 33 lines · Daniel Golle
Quoted 11 lines · Diederik de Haas
Quoted 1 line · 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
[email protected]/>
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.
Quoted 13 lines
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
Quoted 2 lines
I doubt this is per-board. The RNG is inside the SoC, so it could be a chip quality thing.

Quoted 7 lines

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.

Quoted 7 lines

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".

Quoted 14 lines

4. Hope/Ask for more test results
Quoted 1 line
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
```

Chen-Yu Tsai

2024-07-17 08:38 UTC #21 lore raw

In reply to Diederik de Haas

Quoted 75 lines · Diederik de Haas

Quoted 48 lines · On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:
Quoted 33 lines · Daniel Golle
Quoted 11 lines · Diederik de Haas
Quoted 1 line · 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
[email protected]/>
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.
Quoted 13 lines
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
Quoted 2 lines
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
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.
4. Hope/Ask for more test results
Quoted 1 line
On the RK3399 we also saw wildly varying results.
On my Rock64('s) (RK3328) it doesn't work at all:

Quoted 8 lines

```
root@cs21:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
cat: /dev/hwrng: No such device
rngtest: entropy source drained
```

RK3399 and RK3328 are covered by a different driver:

https://lore.kernel.org/all/[email protected]/

And that patch says the TRNG on the RK3328 is utterly broken.

ChenYu

Quoted 2 lines

Cheers,
Diederik

Diederik de Haas

2024-07-17 08:49 UTC #22 lore raw

Quoted 11 lines · On Wednesday, 17 July 2024 10:38:40 CEST Chen-Yu Tsai wrote:

Quoted 10 lines

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
```

Quoted 5 lines

RK3399 and RK3328 are covered by a different driver:
https://lore.kernel.org/all/[email protected]/
And that patch says the TRNG on the RK3328 is utterly broken.

Yeah, someone made me aware of that post and then ofc I had to see it for myself ;-)

Cheers,
Diederik

Daniel Golle

author maintainer

2024-07-17 10:44 UTC #23 lore raw

In reply to Diederik de Haas

Quoted 49 lines · Diederik de Haas

Quoted 48 lines · On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:
Quoted 46 lines · Daniel Golle
Quoted 11 lines · Diederik de Haas
Quoted 1 line · 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
[email protected]/>
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

Quoted 6 lines

Quoted 2 lines
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).

There are quite a lot of options regarding the implementation of an in-SoC RNG. Many of them rely on external components, such as a resistor or simply a pin left floating. Others may be influenced by the power delivery setup. Or rely on "thermal noise generated from inherently random quantum mechanical properties of silicon" (Intel).

I don't know which design Rockchip chose, but just because the RNG is inside the SoC I wouldn't exclude the option that the quality it delivers may depend also on external components on the board, or even the dielectric properties of the board material itself, or (in case of bad designs) environmental circumstances such as the amount of electromagnetic noise around, and that then again depends on relative humidity, exposure to sunlight, ... The latter would be really bad, of course, because then we would have some kind of hidden sensor rather than a RNG, but nothing is too stupid to not show up when engineers of proprietary technologies are left alone.

So imho only empirical data can tell.

Quoted 9 lines

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
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.

+1 Will do.

Quoted 21 lines

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.
4. Hope/Ask for more test results
Quoted 1 line
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
```
Cheers,
Diederik

Dragan Simic

2024-07-17 03:15 UTC #24 lore raw

In reply to Daniel Golle

Hello Daniel,

Quoted 20 lines · Daniel Golle

Quoted 10 lines · Diederik de Haas
Quoted 1 line · 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

Quoted 1 line

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.

Quoted 20 lines

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

Chen-Yu Tsai

2024-07-22 17:57 UTC #25 lore raw

In reply to Diederik de Haas

Quoted 154 lines · Diederik de Haas

Quoted 105 lines · On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
Quoted 74 lines · Diederik de Haas
Quoted 34 lines · On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
For shits and giggles, I tried it on my PineTab2 too (also rk3566):
===========================================================
root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
(2024-04-24) aarch64 GNU/Linux
root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 730
rngtest: FIPS 140-2 failures: 270
rngtest: FIPS 140-2(2001-10-10) Monobit: 266
rngtest: FIPS 140-2(2001-10-10) Poker: 23
rngtest: FIPS 140-2(2001-10-10) Runs: 9
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=2.615; avg=137.889; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 microseconds
===========================================================
Quoted 5 lines
That's looking quite a lot better ... and I have no idea why.
The Q64-A is used as headless server and the PineTab2 is not, but I connected to both over SSH and they were freshly booted into, thus I haven't actually/normally used the PT2 since boot.
I did freshly install rng-tools5 package before running the test, so I rebooted again to make sure that wasn't a factor:
===========================================================
root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 704
rngtest: FIPS 140-2 failures: 296
rngtest: FIPS 140-2(2001-10-10) Monobit: 293
rngtest: FIPS 140-2(2001-10-10) Poker: 32
rngtest: FIPS 140-2(2001-10-10) Runs: 10
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=2.612; avg=137.833; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s rngtest: Program run time: 149736205 microseconds
===========================================================
So that 704/296 vs 730/270 in the previous run on the PT2.
In case it helps:
===========================================================
root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0
Quoted 6 lines
root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0
===========================================================
On my Rock 3A:
wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
rngtest 5
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: 992
rngtest: FIPS 140-2 failures: 8
rngtest: FIPS 140-2(2001-10-10) Monobit: 7
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.658; avg=140.067; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=26.751; avg=34.901; max=65.320)Mibits/s rngtest: Program run time: 147367594 microseconds
Quoted 3 lines
wens@rock-3a:~$ uname -a
Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux
I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before the actual test run made a difference.
Tried it on my Quartz64 Model A: no
Then I tried it on my Quartz64 Model B:
root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 120
rngtest: FIPS 140-2 failures: 880
rngtest: FIPS 140-2(2001-10-10) Monobit: 879
rngtest: FIPS 140-2(2001-10-10) Poker: 332
rngtest: FIPS 140-2(2001-10-10) Runs: 91
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=2.615; avg=138.117; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=20.777; avg=34.535; max=68.857)Mibits/s
rngtest: Program run time: 149461754 microseconds
root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s
root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 104
rngtest: FIPS 140-2 failures: 896
rngtest: FIPS 140-2(2001-10-10) Monobit: 892
rngtest: FIPS 140-2(2001-10-10) Poker: 335
rngtest: FIPS 140-2(2001-10-10) Runs: 79
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=2.613; avg=138.098; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=20.465; avg=34.587; max=69.107)Mibits/s
rngtest: Program run time: 149475187 microseconds

Quoted 4 lines

root@quartz64b:~# uname -a
Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24) aarch64 GNU/Linux

:-O

I pulled out my Quartz64 model B, and the results seem better than yours.

root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
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: 859
rngtest: FIPS 140-2 failures: 141
rngtest: FIPS 140-2(2001-10-10) Monobit: 137
rngtest: FIPS 140-2(2001-10-10) Poker: 10
rngtest: FIPS 140-2(2001-10-10) Runs: 5
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=134.990; avg=143.460; max=157.836)Kibits/s
rngtest: FIPS tests speed: (min=34.742; avg=40.675; max=41.285)Mibits/s
rngtest: Program run time: 136667679 microseconds

root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
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: 843
rngtest: FIPS 140-2 failures: 157
rngtest: FIPS 140-2(2001-10-10) Monobit: 155
rngtest: FIPS 140-2(2001-10-10) Poker: 13
rngtest: FIPS 140-2(2001-10-10) Runs: 7
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=134.977; avg=143.669; max=157.906)Kibits/s
rngtest: FIPS tests speed: (min=37.036; avg=40.666; max=41.285)Mibits/s
rngtest: Program run time: 136459178 microseconds

Diederik de Haas

2024-07-22 19:04 UTC #26 lore raw

Quoted 1 line · On Monday, 22 July 2024 19:57:05 CEST Chen-Yu Tsai wrote:

On Wed, Jul 17, 2024 at 12:54 AM Diederik de Haas <[email protected]>

Quoted 2 lines · wrote:

Quoted 2 lines · On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
Quoted 1 line
On Jul 16, 2024 at 10:13 PM Diederik de Haas <[email protected]>

Quoted 91 lines · wrote:

Quoted 84 lines
Quoted 53 lines
Quoted 41 lines · On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
Quoted 21 lines
For shits and giggles, I tried it on my PineTab2 too (also rk3566):
===========================================================
root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
(2024-04-24) aarch64 GNU/Linux
root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 730
rngtest: FIPS 140-2 failures: 270
===========================================================
Quoted 5 lines
That's looking quite a lot better ... and I have no idea why.
The Q64-A is used as headless server and the PineTab2 is not, but I connected to both over SSH and they were freshly booted into, thus I haven't actually/normally used the PT2 since boot.
I did freshly install rng-tools5 package before running the test, so I rebooted again to make sure that wasn't a factor:
===========================================================
root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 704
rngtest: FIPS 140-2 failures: 296
===========================================================
Quoted 2 lines
So that 704/296 vs 730/270 in the previous run on the PT2.
On my Rock 3A:
wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 992
rngtest: FIPS 140-2 failures: 8
Quoted 3 lines
wens@rock-3a:~$ uname -a
Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux
I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before the actual test run made a difference.
Tried it on my Quartz64 Model A: no
Then I tried it on my Quartz64 Model B:
root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 120
rngtest: FIPS 140-2 failures: 880
root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s
root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 104
rngtest: FIPS 140-2 failures: 896
Quoted 4 lines
root@quartz64b:~# uname -a
Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
(2024-04-24) aarch64 GNU/Linux> 
:-O
I pulled out my Quartz64 model B, and the results seem better than yours.

Quoted 14 lines

root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 859
rngtest: FIPS 140-2 failures: 141
root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 843
rngtest: FIPS 140-2 failures: 157

I noticed you used ``dd`` instead of ``cat``, so I tried again ...

Quartz64-A:

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...                                                               
rngtest: bits received from input: 20000032                                                   
rngtest: FIPS 140-2 successes: 411                                                            
rngtest: FIPS 140-2 failures: 589

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: starting FIPS tests...           
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 391         
rngtest: FIPS 140-2 failures: 609

root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in                             
1+0 records out                   
100000 bytes (100 kB, 98 KiB) copied, 5.66202 s, 17.7 kB/s

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 386                                                            
rngtest: FIPS 140-2 failures: 614

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 356
rngtest: FIPS 140-2 failures: 644

Quartz64-B:

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 118
rngtest: FIPS 140-2 failures: 882

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 133
rngtest: FIPS 140-2 failures: 867

root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 97
rngtest: FIPS 140-2 failures: 903

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 130
rngtest: FIPS 140-2 failures: 870

And lastly on PineTab2:

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 705
rngtest: FIPS 140-2 failures: 295

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 678
rngtest: FIPS 140-2 failures: 322

root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 681
rngtest: FIPS 140-2 failures: 319

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 669
rngtest: FIPS 140-2 failures: 331

So my Q64-B tests are consistently MUCH worse then your Q64-B tests ... This seems BAD to me, now that we even have completely different results per device of the EXACT same model?!? Hardware revision may be different (I have a v1.4), but it seems rather pointless to go into that direction.

It then also seems rather pointless to try it with different parameters if the results on the same SBC model can vary this much.

Thanks for your tests,
Diederik

Dragan Simic

2024-07-24 06:07 UTC #27 lore raw

Hello Diederik and Chen-Yu,

Quoted 196 lines · Diederik de Haas

Quoted 1 line · On Monday, 22 July 2024 19:57:05 CEST Chen-Yu Tsai wrote:

On Wed, Jul 17, 2024 at 12:54 AM Diederik de Haas <[email protected]>

Quoted 2 lines · wrote:

Quoted 2 lines · On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
Quoted 1 line
On Jul 16, 2024 at 10:13 PM Diederik de Haas <[email protected]>

Quoted 91 lines · wrote:

Quoted 84 lines
Quoted 53 lines
Quoted 41 lines · On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
Quoted 21 lines
For shits and giggles, I tried it on my PineTab2 too (also rk3566):
===========================================================
root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
(2024-04-24) aarch64 GNU/Linux
root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 730
rngtest: FIPS 140-2 failures: 270
===========================================================
Quoted 5 lines
That's looking quite a lot better ... and I have no idea why.
The Q64-A is used as headless server and the PineTab2 is not, but I connected to both over SSH and they were freshly booted into, thus I haven't actually/normally used the PT2 since boot.
I did freshly install rng-tools5 package before running the test, so I rebooted again to make sure that wasn't a factor:
===========================================================
root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 704
rngtest: FIPS 140-2 failures: 296
===========================================================
Quoted 2 lines
So that 704/296 vs 730/270 in the previous run on the PT2.
On my Rock 3A:
wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 992
rngtest: FIPS 140-2 failures: 8
Quoted 3 lines
wens@rock-3a:~$ uname -a
Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux
I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before the actual test run made a difference.
Tried it on my Quartz64 Model A: no
Then I tried it on my Quartz64 Model B:
root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 120
rngtest: FIPS 140-2 failures: 880
root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s
root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 104
rngtest: FIPS 140-2 failures: 896
Quoted 4 lines
root@quartz64b:~# uname -a
Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
(2024-04-24) aarch64 GNU/Linux>
:-O
I pulled out my Quartz64 model B, and the results seem better than yours.

Quoted 14 lines

root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 859
rngtest: FIPS 140-2 failures: 141
root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 843
rngtest: FIPS 140-2 failures: 157

I noticed you used ``dd`` instead of ``cat``, so I tried again ...

Quartz64-A:

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...

rngtest: bits received from input: 20000032

rngtest: FIPS 140-2 successes: 411

rngtest: FIPS 140-2 failures: 589

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 391
rngtest: FIPS 140-2 failures: 609

root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.66202 s, 17.7 kB/s

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 386

rngtest: FIPS 140-2 failures: 614

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 356
rngtest: FIPS 140-2 failures: 644

Quartz64-B:

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 118
rngtest: FIPS 140-2 failures: 882

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 133
rngtest: FIPS 140-2 failures: 867

root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 97
rngtest: FIPS 140-2 failures: 903

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 130
rngtest: FIPS 140-2 failures: 870

And lastly on PineTab2:

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 705
rngtest: FIPS 140-2 failures: 295

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 678
rngtest: FIPS 140-2 failures: 322

root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 681
rngtest: FIPS 140-2 failures: 319

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 669
rngtest: FIPS 140-2 failures: 331

Quoted 7 lines

So my Q64-B tests are consistently MUCH worse then your Q64-B tests ... This seems BAD to me, now that we even have completely different results per device of the EXACT same model?!? Hardware revision may be different (I have a v1.4), but it seems rather pointless to go into that direction.
It then also seems rather pointless to try it with different parameters if the results on the same SBC model can vary this much.

Thanks a lot for the testing. Though, such wildly different test results can, regrettably, lead to only one conclusion: the HWRNG found in RK3566 is unusable. :/

Daniel Golle

author maintainer

2024-07-29 23:19 UTC #28 lore raw

Quoted 3 lines · Dragan Simic

Thanks a lot for the testing. Though, such wildly different test results can, regrettably, lead to only one conclusion: the HWRNG found in RK3566 is unusable. :/

The results on RK3568 look much better and the series right now also only enabled the RNG on RK3568 systems. However, we have only seen few boards with RK3568 up to now, and I only got a couple of NanoPi R5C here to test, all with good hwrng results.

Do you think it would be agreeable to only enable the HWRNG for RK3568 as suggested in this series? Or are we expecting quality to also vary as much as it (sadly) does for RK3566?

Diederik de Haas

2024-07-30 09:03 UTC #29 lore raw

Quoted 4 lines · On Tuesday, 30 July 2024 01:18:37 CEST Daniel Golle wrote:

Quoted 3 lines · Dragan Simic
Thanks a lot for the testing. Though, such wildly different test results can, regrettably, lead to only one conclusion: the HWRNG found in RK3566 is unusable. :/

FTR: I agree with Dragan, unfortunately.

Quoted 8 lines

The results on RK3568 look much better and the series right now also only enabled the RNG on RK3568 systems. However, we have only seen few boards with RK3568 up to now, and I only got a couple of NanoPi R5C here to test, all with good hwrng results.
Do you think it would be agreeable to only enable the HWRNG for RK3568 as suggested in this series? Or are we expecting quality to also vary as much as it (sadly) does for RK3566?

Unless we get *evidence* to the contrary, we should assume that the HWRNG on RK3568 is fine as the currently available test results are fine. So I think enabling it only for RK3568 is the right thing to do.

So a 'revert' to v7 variant seems appropriate, but with the following changes:
- Add status = "disabled"; property to the definition in rk356x.dtsi
- Add a new commit where you enable it only for rk3568 and document in the commit message why it's not enabled on rk3566 with a possible link to the v7 thread for clarification on why that is

You could probably also integrate that into 1 commit, but make sure that the commit summary and description match the implementation.
IMO that wasn't 'technically' the case in v8 as the rng node was added to rk356x, but it was only enabled on rk3568.

My 0.02

Heiko Stübner

maintainer

2024-07-30 10:37 UTC #30 lore raw

Am Dienstag, 30. Juli 2024, 11:03:06 CEST schrieb Diederik de Haas:

Quoted 21 lines · On Tuesday, 30 July 2024 01:18:37 CEST Daniel Golle wrote:

Quoted 4 lines · Dragan Simic
Quoted 3 lines
Thanks a lot for the testing. Though, such wildly different test results can, regrettably, lead to only one conclusion: the HWRNG found in RK3566 is unusable. :/
FTR: I agree with Dragan, unfortunately.
Quoted 8 lines
The results on RK3568 look much better and the series right now also only enabled the RNG on RK3568 systems. However, we have only seen few boards with RK3568 up to now, and I only got a couple of NanoPi R5C here to test, all with good hwrng results.
Do you think it would be agreeable to only enable the HWRNG for RK3568 as suggested in this series? Or are we expecting quality to also vary as much as it (sadly) does for RK3566?
Unless we get *evidence* to the contrary, we should assume that the HWRNG on RK3568 is fine as the currently available test results are fine. So I think enabling it only for RK3568 is the right thing to do.

Quoted 5 lines

So a 'revert' to v7 variant seems appropriate, but with the following changes:
- Add status = "disabled"; property to the definition in rk356x.dtsi
- Add a new commit where you enable it only for rk3568 and document in the commit message why it's not enabled on rk3566 with a possible link to the v7 thread for clarification on why that is

I was going to protest about the "disable" until reading the 2nd part :-D .

And yeah that makes a lot of sense, "add" it to rk356x.dtsi, as the IP is part of both variants, but only enable it in rk3568.dtsi because of the seemingly faulty implementation on the rk3566.

Quoted 6 lines

You could probably also integrate that into 1 commit, but make sure that the commit summary and description match the implementation.
IMO that wasn't 'technically' the case in v8 as the rng node was added to rk356x, but it was only enabled on rk3568.
My 0.02

Chen-Yu Tsai

2024-07-30 12:08 UTC #31 lore raw

Quoted 29 lines · Heiko Stübner

Am Dienstag, 30. Juli 2024, 11:03:06 CEST schrieb Diederik de Haas:
Quoted 21 lines · On Tuesday, 30 July 2024 01:18:37 CEST Daniel Golle wrote:
Quoted 4 lines · Dragan Simic
Quoted 3 lines
Thanks a lot for the testing. Though, such wildly different test results can, regrettably, lead to only one conclusion: the HWRNG found in RK3566 is unusable. :/
FTR: I agree with Dragan, unfortunately.
Quoted 8 lines
The results on RK3568 look much better and the series right now also only enabled the RNG on RK3568 systems. However, we have only seen few boards with RK3568 up to now, and I only got a couple of NanoPi R5C here to test, all with good hwrng results.
Do you think it would be agreeable to only enable the HWRNG for RK3568 as suggested in this series? Or are we expecting quality to also vary as much as it (sadly) does for RK3566?
Unless we get *evidence* to the contrary, we should assume that the HWRNG on RK3568 is fine as the currently available test results are fine. So I think enabling it only for RK3568 is the right thing to do.
Quoted 5 lines
So a 'revert' to v7 variant seems appropriate, but with the following changes:
- Add status = "disabled"; property to the definition in rk356x.dtsi
- Add a new commit where you enable it only for rk3568 and document in the commit message why it's not enabled on rk3566 with a possible link to the v7 thread for clarification on why that is

Quoted 5 lines

I was going to protest about the "disable" until reading the 2nd part :-D .
And yeah that makes a lot of sense, "add" it to rk356x.dtsi, as the IP is part of both variants, but only enable it in rk3568.dtsi because of the seemingly faulty implementation on the rk3566.

Better yet, mark it as "broken" in rk3566.dtsi to reflect the tests that we've all done.

ChenYu

Quoted 10 lines

Quoted 6 lines
You could probably also integrate that into 1 commit, but make sure that the commit summary and description match the implementation.
IMO that wasn't 'technically' the case in v8 as the rng node was added to rk356x, but it was only enabled on rk3568.
My 0.02

Dragan Simic

2024-08-01 16:49 UTC #32 lore raw

In reply to Daniel Golle

Hello Daniel,

Quoted 5 lines · Daniel Golle

Quoted 3 lines · Dragan Simic
Thanks a lot for the testing. Though, such wildly different test results can, regrettably, lead to only one conclusion: the HWRNG found in RK3566 is unusable. :/

Quoted 8 lines

The results on RK3568 look much better and the series right now also only enabled the RNG on RK3568 systems. However, we have only seen few boards with RK3568 up to now, and I only got a couple of NanoPi R5C here to test, all with good hwrng results.
Do you think it would be agreeable to only enable the HWRNG for RK3568 as suggested in this series? Or are we expecting quality to also vary as much as it (sadly) does for RK3566?

I'm a bit late to the party, sorry for that. The test results so far show that the HWRNG in RK3566 simply cannot be relied upon, but the test results also show that the RK3568's HWRNG seems fine. I'm wondering why, but until we bump into a sample of RK3568 whose HWRNG performs badly, I'd say that enabling the HWRNG on RK3568 only is safe.

Of course, as other people already noted, the HWRNG should be defined in rk356x.dtsi, because it does exist in both SoC variants, but should be enabled in rk3568.dtsi only. As already noted, describing it as broken on RK3566 in rk356x.dtsi should also be good.

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip