linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v5 0/3] MediaTek Security random number generator support
@ 2019-11-27 14:22 Neal Liu
  2019-11-27 14:22 ` [PATCH v5 1/3] soc: mediatek: add SMC fid table for SIP interface Neal Liu
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Neal Liu @ 2019-11-27 14:22 UTC (permalink / raw)
  To: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland,
	Matthias Brugger, Sean Wang
  Cc: devicetree, wsd_upstream, linux-kernel, Crystal Guo,
	linux-crypto, Neal Liu, linux-mediatek, linux-arm-kernel

These patch series introduce a generic rng driver for Trustzone
based kernel driver which would like to communicate with ATF
SIP services.

Patch #1 initials SMC fid table for Mediatek SIP interfaces and
adds HWRNG related SMC call.

Patch #2..3 adds mtk-sec-rng kernel driver for Trustzone based SoCs.
For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
entropy sources is not accessible from normal world (linux) and
rather accessible from secure world (ATF/TEE) only.
This driver aims to provide a generic interface to ATF rng service.


changes since v1:
- rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can reuse
  this driver.
- refine coding style and unnecessary check.

changes since v2:
- remove unused comments.
- remove redundant variable.

changes since v3:
- add dt-bindings for MediaTek rng with TrustZone enabled.
- revise HWRNG SMC call fid.

changes since v4:
- move bindings to the arm/firmware directory.
- revise driver init flow to check more property.


Neal Liu (3):
  soc: mediatek: add SMC fid table for SIP interface
  dt-bindings: rng: add bindings for MediaTek ARMv8 SoCs
  hwrng: add mtk-sec-rng driver

 .../arm/firmware/mediatek,mtk-sec-rng.txt     |  18 +++
 drivers/char/hw_random/Kconfig                |  16 +++
 drivers/char/hw_random/Makefile               |   1 +
 drivers/char/hw_random/mtk-sec-rng.c          | 103 ++++++++++++++++++
 include/linux/soc/mediatek/mtk_sip_svc.h      |  33 ++++++
 5 files changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/mediatek,mtk-sec-rng.txt
 create mode 100644 drivers/char/hw_random/mtk-sec-rng.c
 create mode 100644 include/linux/soc/mediatek/mtk_sip_svc.h

-- 
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH v5 1/3] soc: mediatek: add SMC fid table for SIP interface
  2019-11-27 14:22 [PATCH v5 0/3] MediaTek Security random number generator support Neal Liu
@ 2019-11-27 14:22 ` Neal Liu
  2019-11-27 14:22 ` [PATCH v5 2/3] dt-bindings: rng: add bindings for MediaTek ARMv8 SoCs Neal Liu
  2019-11-27 14:22 ` [PATCH v5 3/3] hwrng: add mtk-sec-rng driver Neal Liu
  2 siblings, 0 replies; 18+ messages in thread
From: Neal Liu @ 2019-11-27 14:22 UTC (permalink / raw)
  To: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland,
	Matthias Brugger, Sean Wang
  Cc: devicetree, wsd_upstream, linux-kernel, Crystal Guo,
	linux-crypto, Neal Liu, linux-mediatek, linux-arm-kernel

1. Add a header file to provide SIP interface to ATF
2. Add hwrng SMC fid

Signed-off-by: Neal Liu <neal.liu@mediatek.com>
---
 include/linux/soc/mediatek/mtk_sip_svc.h |   33 ++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 include/linux/soc/mediatek/mtk_sip_svc.h

diff --git a/include/linux/soc/mediatek/mtk_sip_svc.h b/include/linux/soc/mediatek/mtk_sip_svc.h
new file mode 100644
index 0000000..8cc8b5c
--- /dev/null
+++ b/include/linux/soc/mediatek/mtk_sip_svc.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#ifndef _MTK_SECURE_API_H_
+#define _MTK_SECURE_API_H_
+
+#include <linux/kernel.h>
+
+/* Error Code */
+#define SIP_SVC_E_SUCCESS		0
+#define SIP_SVC_E_NOT_SUPPORTED		-1
+#define SIP_SVC_E_INVALID_PARAMS	-2
+#define SIP_SVC_E_INVALID_RANGE		-3
+#define SIP_SVC_E_PERMISSION_DENY	-4
+
+#ifdef CONFIG_ARM64
+#define MTK_SIP_SMC_AARCH_BIT		BIT(30)
+#else
+#define MTK_SIP_SMC_AARCH_BIT		0
+#endif
+
+/*******************************************************************************
+ * Defines for Mediatek runtime services func ids
+ ******************************************************************************/
+
+/* Security related SMC call */
+/* HWRNG */
+#define MTK_SIP_KERNEL_GET_RND \
+	(0x8200026A | MTK_SIP_SMC_AARCH_BIT)
+
+#endif /* _MTK_SECURE_API_H_ */
-- 
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v5 2/3] dt-bindings: rng: add bindings for MediaTek ARMv8 SoCs
  2019-11-27 14:22 [PATCH v5 0/3] MediaTek Security random number generator support Neal Liu
  2019-11-27 14:22 ` [PATCH v5 1/3] soc: mediatek: add SMC fid table for SIP interface Neal Liu
@ 2019-11-27 14:22 ` Neal Liu
  2019-11-27 14:22 ` [PATCH v5 3/3] hwrng: add mtk-sec-rng driver Neal Liu
  2 siblings, 0 replies; 18+ messages in thread
From: Neal Liu @ 2019-11-27 14:22 UTC (permalink / raw)
  To: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland,
	Matthias Brugger, Sean Wang
  Cc: devicetree, wsd_upstream, linux-kernel, Crystal Guo,
	linux-crypto, Neal Liu, linux-mediatek, linux-arm-kernel

Document the binding used by the MediaTek ARMv8 SoCs random
number generator with TrustZone enabled.

Signed-off-by: Neal Liu <neal.liu@mediatek.com>
---
 .../bindings/arm/firmware/mediatek,mtk-sec-rng.txt |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/mediatek,mtk-sec-rng.txt

diff --git a/Documentation/devicetree/bindings/arm/firmware/mediatek,mtk-sec-rng.txt b/Documentation/devicetree/bindings/arm/firmware/mediatek,mtk-sec-rng.txt
new file mode 100644
index 0000000..741fcdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/mediatek,mtk-sec-rng.txt
@@ -0,0 +1,18 @@
+MediaTek random number generator with TrustZone enabled
+
+Required properties:
+- compatible       : Should contain "mediatek,mtk-sec-rng"
+
+- method           : The method of calling Arm Trusted Firmware. Permitted
+		     values are:
+
+		     "smc" : SMC #0, with the register assignments specified
+		     in this binding.
+
+Example:
+	firmware {
+		hwrng {
+			compatible = "mediatek,mtk-sec-rng";
+			methods = "smc";
+		};
+	};
-- 
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-11-27 14:22 [PATCH v5 0/3] MediaTek Security random number generator support Neal Liu
  2019-11-27 14:22 ` [PATCH v5 1/3] soc: mediatek: add SMC fid table for SIP interface Neal Liu
  2019-11-27 14:22 ` [PATCH v5 2/3] dt-bindings: rng: add bindings for MediaTek ARMv8 SoCs Neal Liu
@ 2019-11-27 14:22 ` Neal Liu
  2019-11-27 15:03   ` Ard Biesheuvel
  2019-11-29 10:02   ` Lars Persson
  2 siblings, 2 replies; 18+ messages in thread
From: Neal Liu @ 2019-11-27 14:22 UTC (permalink / raw)
  To: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland,
	Matthias Brugger, Sean Wang
  Cc: devicetree, wsd_upstream, linux-kernel, Crystal Guo,
	linux-crypto, Neal Liu, linux-mediatek, linux-arm-kernel

For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
entropy sources is not accessible from normal world (linux) and
rather accessible from secure world (ATF/TEE) only. This driver aims
to provide a generic interface to ATF rng service.

Signed-off-by: Neal Liu <neal.liu@mediatek.com>
---
 drivers/char/hw_random/Kconfig       |   16 ++++++
 drivers/char/hw_random/Makefile      |    1 +
 drivers/char/hw_random/mtk-sec-rng.c |  103 ++++++++++++++++++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 drivers/char/hw_random/mtk-sec-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 25a7d8f..f08c852 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -398,6 +398,22 @@ config HW_RANDOM_MTK
 
 	  If unsure, say Y.
 
+config HW_RANDOM_MTK_SEC
+	tristate "MediaTek Security Random Number Generator support"
+	depends on HW_RANDOM
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	default HW_RANDOM
+	  help
+	  This driver provides kernel-side support for the Random Number
+	  Generator hardware found on MediaTek SoCs. The difference with
+	  mtk-rng is the Random Number Generator hardware is secure
+	  access only.
+
+	  To compile this driver as a module, choose M here. the
+	  module will be called mtk-sec-rng.
+
+	  If unsure, say Y.
+
 config HW_RANDOM_S390
 	tristate "S390 True Random Number Generator support"
 	depends on S390
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 7c9ef4a..bee5412 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
 obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
 obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
 obj-$(CONFIG_HW_RANDOM_MTK)	+= mtk-rng.o
+obj-$(CONFIG_HW_RANDOM_MTK_SEC)	+= mtk-sec-rng.o
 obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
 obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
 obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
diff --git a/drivers/char/hw_random/mtk-sec-rng.c b/drivers/char/hw_random/mtk-sec-rng.c
new file mode 100644
index 0000000..69ddeca
--- /dev/null
+++ b/drivers/char/hw_random/mtk-sec-rng.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/hw_random.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/soc/mediatek/mtk_sip_svc.h>
+
+#define MTK_SEC_RNG_MAGIC	0x74726e67
+#define SMC_RET_NUM		4
+#define MTK_SEC_RND_SIZE	(sizeof(u32) * SMC_RET_NUM)
+
+static void mtk_sec_get_rnd(uint32_t *val)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_smc(MTK_SIP_KERNEL_GET_RND,
+		      MTK_SEC_RNG_MAGIC, 0, 0, 0, 0, 0, 0, &res);
+
+	val[0] = res.a0;
+	val[1] = res.a1;
+	val[2] = res.a2;
+	val[3] = res.a3;
+}
+
+static int mtk_sec_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+	u32 val[4] = {0};
+	int retval = 0;
+	int i;
+
+	while (max >= MTK_SEC_RND_SIZE) {
+		mtk_sec_get_rnd(val);
+
+		for (i = 0; i < SMC_RET_NUM; i++) {
+			*(u32 *)buf = val[i];
+			buf += sizeof(u32);
+		}
+
+		retval += MTK_SEC_RND_SIZE;
+		max -= MTK_SEC_RND_SIZE;
+	}
+
+	return retval;
+}
+
+static struct hwrng mtk_sec_rng = {
+	.name = "mtk_sec_rng",
+	.read = mtk_sec_rng_read,
+	.quality = 900,
+};
+
+static int mtk_sec_rng_probe(void)
+{
+	int ret;
+
+	ret = hwrng_register(&mtk_sec_rng);
+	if (ret) {
+		pr_err("Failed to register rng device: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int __init mtk_sec_rng_driver_init(void)
+{
+	struct device_node *fw_np;
+	struct device_node *np;
+	const char *method;
+
+	fw_np = of_find_node_by_name(NULL, "firmware");
+	if (!fw_np)
+		return -ENODEV;
+
+	np = of_find_compatible_node(fw_np, NULL, "mediatek,mtk-sec-rng");
+	if (!np)
+		return -ENODEV;
+
+	if (of_property_read_string(np, "method", &method))
+		return -ENXIO;
+
+	if (strncmp("smc", method, strlen("smc")))
+		return -EINVAL;
+
+	return mtk_sec_rng_probe();
+}
+
+static void __exit mtk_sec_rng_driver_exit(void)
+{
+	hwrng_unregister(&mtk_sec_rng);
+}
+
+module_init(mtk_sec_rng_driver_init);
+module_exit(mtk_sec_rng_driver_exit);
+
+MODULE_DESCRIPTION("MediaTek Security Random Number Generator Driver");
+MODULE_AUTHOR("Neal Liu <neal.liu@mediatek.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-11-27 14:22 ` [PATCH v5 3/3] hwrng: add mtk-sec-rng driver Neal Liu
@ 2019-11-27 15:03   ` Ard Biesheuvel
  2019-11-28 15:02     ` Neal Liu
  2019-11-29 10:02   ` Lars Persson
  1 sibling, 1 reply; 18+ messages in thread
From: Ard Biesheuvel @ 2019-11-27 15:03 UTC (permalink / raw)
  To: Neal Liu
  Cc: Mark Rutland, Devicetree List, Herbert Xu, wsd_upstream,
	Sean Wang, Linux Kernel Mailing List, Rob Herring, Crystal Guo,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Matt Mackall,
	Matthias Brugger, moderated list:ARM/Mediatek SoC support,
	linux-arm-kernel

On Wed, 27 Nov 2019 at 15:23, Neal Liu <neal.liu@mediatek.com> wrote:
>
> For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> entropy sources is not accessible from normal world (linux) and
> rather accessible from secure world (ATF/TEE) only. This driver aims
> to provide a generic interface to ATF rng service.
>
> Signed-off-by: Neal Liu <neal.liu@mediatek.com>
> ---
>  drivers/char/hw_random/Kconfig       |   16 ++++++
>  drivers/char/hw_random/Makefile      |    1 +
>  drivers/char/hw_random/mtk-sec-rng.c |  103 ++++++++++++++++++++++++++++++++++
>  3 files changed, 120 insertions(+)
>  create mode 100644 drivers/char/hw_random/mtk-sec-rng.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 25a7d8f..f08c852 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -398,6 +398,22 @@ config HW_RANDOM_MTK
>
>           If unsure, say Y.
>
> +config HW_RANDOM_MTK_SEC
> +       tristate "MediaTek Security Random Number Generator support"
> +       depends on HW_RANDOM
> +       depends on ARCH_MEDIATEK || COMPILE_TEST
> +       default HW_RANDOM
> +         help
> +         This driver provides kernel-side support for the Random Number
> +         Generator hardware found on MediaTek SoCs. The difference with
> +         mtk-rng is the Random Number Generator hardware is secure
> +         access only.
> +
> +         To compile this driver as a module, choose M here. the
> +         module will be called mtk-sec-rng.
> +
> +         If unsure, say Y.
> +
>  config HW_RANDOM_S390
>         tristate "S390 True Random Number Generator support"
>         depends on S390
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index 7c9ef4a..bee5412 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
>  obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
>  obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
>  obj-$(CONFIG_HW_RANDOM_MTK)    += mtk-rng.o
> +obj-$(CONFIG_HW_RANDOM_MTK_SEC)        += mtk-sec-rng.o
>  obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
>  obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
>  obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
> diff --git a/drivers/char/hw_random/mtk-sec-rng.c b/drivers/char/hw_random/mtk-sec-rng.c
> new file mode 100644
> index 0000000..69ddeca
> --- /dev/null
> +++ b/drivers/char/hw_random/mtk-sec-rng.c
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 MediaTek Inc.
> + */
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/hw_random.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/soc/mediatek/mtk_sip_svc.h>
> +
> +#define MTK_SEC_RNG_MAGIC      0x74726e67
> +#define SMC_RET_NUM            4
> +#define MTK_SEC_RND_SIZE       (sizeof(u32) * SMC_RET_NUM)
> +
> +static void mtk_sec_get_rnd(uint32_t *val)
> +{
> +       struct arm_smccc_res res;
> +
> +       arm_smccc_smc(MTK_SIP_KERNEL_GET_RND,
> +                     MTK_SEC_RNG_MAGIC, 0, 0, 0, 0, 0, 0, &res);
> +

Can this call never fail? How does the firmware signal that something
is wrong with the underlying hardware?

> +       val[0] = res.a0;
> +       val[1] = res.a1;
> +       val[2] = res.a2;
> +       val[3] = res.a3;
> +}
> +
> +static int mtk_sec_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> +       u32 val[4] = {0};
> +       int retval = 0;
> +       int i;
> +
> +       while (max >= MTK_SEC_RND_SIZE) {
> +               mtk_sec_get_rnd(val);
> +
> +               for (i = 0; i < SMC_RET_NUM; i++) {
> +                       *(u32 *)buf = val[i];
> +                       buf += sizeof(u32);
> +               }
> +
> +               retval += MTK_SEC_RND_SIZE;
> +               max -= MTK_SEC_RND_SIZE;
> +       }
> +
> +       return retval;
> +}
> +
> +static struct hwrng mtk_sec_rng = {
> +       .name = "mtk_sec_rng",
> +       .read = mtk_sec_rng_read,
> +       .quality = 900,
> +};
> +
> +static int mtk_sec_rng_probe(void)
> +{
> +       int ret;
> +
> +       ret = hwrng_register(&mtk_sec_rng);
> +       if (ret) {
> +               pr_err("Failed to register rng device: %d\n", ret);
> +               return ret;
> +       }
> +
> +       return 0;
> +}
> +
> +static int __init mtk_sec_rng_driver_init(void)
> +{
> +       struct device_node *fw_np;
> +       struct device_node *np;
> +       const char *method;
> +
> +       fw_np = of_find_node_by_name(NULL, "firmware");
> +       if (!fw_np)
> +               return -ENODEV;
> +
> +       np = of_find_compatible_node(fw_np, NULL, "mediatek,mtk-sec-rng");
> +       if (!np)
> +               return -ENODEV;
> +
> +       if (of_property_read_string(np, "method", &method))
> +               return -ENXIO;
> +
> +       if (strncmp("smc", method, strlen("smc")))
> +               return -EINVAL;
> +
> +       return mtk_sec_rng_probe();
> +}
> +
> +static void __exit mtk_sec_rng_driver_exit(void)
> +{
> +       hwrng_unregister(&mtk_sec_rng);
> +}
> +
> +module_init(mtk_sec_rng_driver_init);
> +module_exit(mtk_sec_rng_driver_exit);
> +
> +MODULE_DESCRIPTION("MediaTek Security Random Number Generator Driver");
> +MODULE_AUTHOR("Neal Liu <neal.liu@mediatek.com>");
> +MODULE_LICENSE("GPL");
> --
> 1.7.9.5

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-11-27 15:03   ` Ard Biesheuvel
@ 2019-11-28 15:02     ` Neal Liu
  0 siblings, 0 replies; 18+ messages in thread
From: Neal Liu @ 2019-11-28 15:02 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Mark Rutland, Devicetree List, Herbert Xu, wsd_upstream,
	Sean Wang, moderated list:ARM/Mediatek SoC support,
	Linux Kernel Mailing List, Rob Herring, Neal Liu,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Matt Mackall,
	Matthias Brugger, Crystal Guo (郭晶),
	linux-arm-kernel

On Wed, 2019-11-27 at 23:03 +0800, Ard Biesheuvel wrote:
> On Wed, 27 Nov 2019 at 15:23, Neal Liu <neal.liu@mediatek.com> wrote:
> >
> > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > entropy sources is not accessible from normal world (linux) and
> > rather accessible from secure world (ATF/TEE) only. This driver aims
> > to provide a generic interface to ATF rng service.
> >
> > Signed-off-by: Neal Liu <neal.liu@mediatek.com>
> > ---
> >  drivers/char/hw_random/Kconfig       |   16 ++++++
> >  drivers/char/hw_random/Makefile      |    1 +
> >  drivers/char/hw_random/mtk-sec-rng.c |  103 ++++++++++++++++++++++++++++++++++
> >  3 files changed, 120 insertions(+)
> >  create mode 100644 drivers/char/hw_random/mtk-sec-rng.c
> >
> > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> > index 25a7d8f..f08c852 100644
> > --- a/drivers/char/hw_random/Kconfig
> > +++ b/drivers/char/hw_random/Kconfig
> > @@ -398,6 +398,22 @@ config HW_RANDOM_MTK
> >
> >           If unsure, say Y.
> >
> > +config HW_RANDOM_MTK_SEC
> > +       tristate "MediaTek Security Random Number Generator support"
> > +       depends on HW_RANDOM
> > +       depends on ARCH_MEDIATEK || COMPILE_TEST
> > +       default HW_RANDOM
> > +         help
> > +         This driver provides kernel-side support for the Random Number
> > +         Generator hardware found on MediaTek SoCs. The difference with
> > +         mtk-rng is the Random Number Generator hardware is secure
> > +         access only.
> > +
> > +         To compile this driver as a module, choose M here. the
> > +         module will be called mtk-sec-rng.
> > +
> > +         If unsure, say Y.
> > +
> >  config HW_RANDOM_S390
> >         tristate "S390 True Random Number Generator support"
> >         depends on S390
> > diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> > index 7c9ef4a..bee5412 100644
> > --- a/drivers/char/hw_random/Makefile
> > +++ b/drivers/char/hw_random/Makefile
> > @@ -36,6 +36,7 @@ obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
> >  obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
> >  obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
> >  obj-$(CONFIG_HW_RANDOM_MTK)    += mtk-rng.o
> > +obj-$(CONFIG_HW_RANDOM_MTK_SEC)        += mtk-sec-rng.o
> >  obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
> >  obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
> >  obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
> > diff --git a/drivers/char/hw_random/mtk-sec-rng.c b/drivers/char/hw_random/mtk-sec-rng.c
> > new file mode 100644
> > index 0000000..69ddeca
> > --- /dev/null
> > +++ b/drivers/char/hw_random/mtk-sec-rng.c
> > @@ -0,0 +1,103 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 MediaTek Inc.
> > + */
> > +
> > +#include <linux/arm-smccc.h>
> > +#include <linux/hw_random.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/soc/mediatek/mtk_sip_svc.h>
> > +
> > +#define MTK_SEC_RNG_MAGIC      0x74726e67
> > +#define SMC_RET_NUM            4
> > +#define MTK_SEC_RND_SIZE       (sizeof(u32) * SMC_RET_NUM)
> > +
> > +static void mtk_sec_get_rnd(uint32_t *val)
> > +{
> > +       struct arm_smccc_res res;
> > +
> > +       arm_smccc_smc(MTK_SIP_KERNEL_GET_RND,
> > +                     MTK_SEC_RNG_MAGIC, 0, 0, 0, 0, 0, 0, &res);
> > +
> 
> Can this call never fail? How does the firmware signal that something
> is wrong with the underlying hardware?
> 

The smc call is supported in both ARMv7 & ARMv8 architectures.But yes,
it should check hardware status before assigning it.

We would like to check that if hardware is something wrong, all return
value will be zero. ex:

	if (!res.a0 && !res.a1 && !res.a2 && !res.a3)
		return false;

> > +       val[0] = res.a0;
> > +       val[1] = res.a1;
> > +       val[2] = res.a2;
> > +       val[3] = res.a3;

	return true;
> > +}
> > +
> > +static int mtk_sec_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> > +{
> > +       u32 val[4] = {0};
> > +       int retval = 0;
> > +       int i;
> > +
> > +       while (max >= MTK_SEC_RND_SIZE) {
> > +               mtk_sec_get_rnd(val);
> > +
> > +               for (i = 0; i < SMC_RET_NUM; i++) {
> > +                       *(u32 *)buf = val[i];
> > +                       buf += sizeof(u32);
> > +               }
> > +
> > +               retval += MTK_SEC_RND_SIZE;
> > +               max -= MTK_SEC_RND_SIZE;
> > +       }
> > +
> > +       return retval;
> > +}
> > +
> > +static struct hwrng mtk_sec_rng = {
> > +       .name = "mtk_sec_rng",
> > +       .read = mtk_sec_rng_read,
> > +       .quality = 900,
> > +};
> > +
> > +static int mtk_sec_rng_probe(void)
> > +{
> > +       int ret;
> > +
> > +       ret = hwrng_register(&mtk_sec_rng);
> > +       if (ret) {
> > +               pr_err("Failed to register rng device: %d\n", ret);
> > +               return ret;
> > +       }
> > +
> > +       return 0;
> > +}
> > +
> > +static int __init mtk_sec_rng_driver_init(void)
> > +{
> > +       struct device_node *fw_np;
> > +       struct device_node *np;
> > +       const char *method;
> > +
> > +       fw_np = of_find_node_by_name(NULL, "firmware");
> > +       if (!fw_np)
> > +               return -ENODEV;
> > +
> > +       np = of_find_compatible_node(fw_np, NULL, "mediatek,mtk-sec-rng");
> > +       if (!np)
> > +               return -ENODEV;
> > +
> > +       if (of_property_read_string(np, "method", &method))
> > +               return -ENXIO;
> > +
> > +       if (strncmp("smc", method, strlen("smc")))
> > +               return -EINVAL;
> > +
> > +       return mtk_sec_rng_probe();
> > +}
> > +
> > +static void __exit mtk_sec_rng_driver_exit(void)
> > +{
> > +       hwrng_unregister(&mtk_sec_rng);
> > +}
> > +
> > +module_init(mtk_sec_rng_driver_init);
> > +module_exit(mtk_sec_rng_driver_exit);
> > +
> > +MODULE_DESCRIPTION("MediaTek Security Random Number Generator Driver");
> > +MODULE_AUTHOR("Neal Liu <neal.liu@mediatek.com>");
> > +MODULE_LICENSE("GPL");
> > --
> > 1.7.9.5
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-11-27 14:22 ` [PATCH v5 3/3] hwrng: add mtk-sec-rng driver Neal Liu
  2019-11-27 15:03   ` Ard Biesheuvel
@ 2019-11-29 10:02   ` Lars Persson
  2019-11-29 11:30     ` Neal Liu
  1 sibling, 1 reply; 18+ messages in thread
From: Lars Persson @ 2019-11-29 10:02 UTC (permalink / raw)
  To: Neal Liu
  Cc: Mark Rutland, DTML, Herbert Xu, wsd_upstream, Sean Wang,
	Linux Kernel Mailing List, Rob Herring, Crystal Guo,
	linux-crypto, Matt Mackall, Matthias Brugger, linux-mediatek,
	linux-arm-kernel

Hi Neal,

On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:
>
> For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> entropy sources is not accessible from normal world (linux) and
> rather accessible from secure world (ATF/TEE) only. This driver aims
> to provide a generic interface to ATF rng service.
>

I am working on several SoCs that also will need this kind of driver
to get entropy from Arm trusted firmware.
If you intend to make this a generic interface, please clean up the
references to MediaTek and give it a more generic name. For example
"Arm Trusted Firmware random number driver".

It will also be helpful if the SMC call number is configurable.

- Lars

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-11-29 10:02   ` Lars Persson
@ 2019-11-29 11:30     ` Neal Liu
  2019-12-02 16:12       ` Ard Biesheuvel
  0 siblings, 1 reply; 18+ messages in thread
From: Neal Liu @ 2019-11-29 11:30 UTC (permalink / raw)
  To: Lars Persson
  Cc: Mark Rutland, DTML, Herbert Xu, wsd_upstream, Sean Wang,
	Linux Kernel Mailing List, Rob Herring,
	Crystal Guo (郭晶),
	linux-crypto, Matt Mackall, Matthias Brugger, linux-mediatek,
	linux-arm-kernel

On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
> Hi Neal,
> 
> On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:
> >
> > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > entropy sources is not accessible from normal world (linux) and
> > rather accessible from secure world (ATF/TEE) only. This driver aims
> > to provide a generic interface to ATF rng service.
> >
> 
> I am working on several SoCs that also will need this kind of driver
> to get entropy from Arm trusted firmware.
> If you intend to make this a generic interface, please clean up the
> references to MediaTek and give it a more generic name. For example
> "Arm Trusted Firmware random number driver".
> 
> It will also be helpful if the SMC call number is configurable.
> 
> - Lars

Yes, I'm trying to make this to a generic interface. I'll try to make
HW/platform related dependency to be configurable and let it more
generic.
Thanks for your suggestion.

> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-11-29 11:30     ` Neal Liu
@ 2019-12-02 16:12       ` Ard Biesheuvel
  2019-12-02 19:11         ` Marc Zyngier
  2019-12-12 14:43         ` Sudeep Holla
  0 siblings, 2 replies; 18+ messages in thread
From: Ard Biesheuvel @ 2019-12-02 16:12 UTC (permalink / raw)
  To: Neal Liu, Catalin Marinas, Will Deacon, Marc Zyngier
  Cc: Mark Rutland, DTML, Herbert Xu, wsd_upstream, Sean Wang,
	Linux Kernel Mailing List, Rob Herring,
	Crystal Guo (郭晶),
	linux-crypto, Matt Mackall, Matthias Brugger, linux-mediatek,
	Lars Persson, linux-arm-kernel

(adding some more arm64 folks)

On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
>
> On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
> > Hi Neal,
> >
> > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:
> > >
> > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > > entropy sources is not accessible from normal world (linux) and
> > > rather accessible from secure world (ATF/TEE) only. This driver aims
> > > to provide a generic interface to ATF rng service.
> > >
> >
> > I am working on several SoCs that also will need this kind of driver
> > to get entropy from Arm trusted firmware.
> > If you intend to make this a generic interface, please clean up the
> > references to MediaTek and give it a more generic name. For example
> > "Arm Trusted Firmware random number driver".
> >
> > It will also be helpful if the SMC call number is configurable.
> >
> > - Lars
>
> Yes, I'm trying to make this to a generic interface. I'll try to make
> HW/platform related dependency to be configurable and let it more
> generic.
> Thanks for your suggestion.
>

I don't think it makes sense for each arm64 platform to expose an
entropy source via SMC calls in a slightly different way, and model it
as a h/w driver. Instead, we should try to standardize this, and
perhaps expose it via the architectural helpers that already exist
(get_random_seed_long() and friends), so they get plugged into the
kernel random pool driver directly.

Note that in addition to drivers based on vendor SMC calls, we already
have a RNG h/w driver based on OP-TEE as well, where the driver
attaches to a standardized trusted OS interface identified by a UUID,
and which also gets invoked via SMC calls into secure firmware.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-02 16:12       ` Ard Biesheuvel
@ 2019-12-02 19:11         ` Marc Zyngier
  2019-12-03  4:16           ` Florian Fainelli
  2019-12-03 10:17           ` Will Deacon
  2019-12-12 14:43         ` Sudeep Holla
  1 sibling, 2 replies; 18+ messages in thread
From: Marc Zyngier @ 2019-12-02 19:11 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Mark Rutland, DTML, Herbert Xu, wsd_upstream, Catalin Marinas,
	Sean Wang, linux-mediatek, Linux Kernel Mailing List,
	Rob Herring, Neal Liu, linux-crypto, Matt Mackall,
	Matthias Brugger, Crystal Guo (郭晶),
	Will Deacon, Lars Persson, linux-arm-kernel

On Mon, 2 Dec 2019 16:12:09 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> (adding some more arm64 folks)
> 
> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
> >
> > On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:  
> > > Hi Neal,
> > >
> > > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:  
> > > >
> > > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > > > entropy sources is not accessible from normal world (linux) and
> > > > rather accessible from secure world (ATF/TEE) only. This driver aims
> > > > to provide a generic interface to ATF rng service.
> > > >  
> > >
> > > I am working on several SoCs that also will need this kind of driver
> > > to get entropy from Arm trusted firmware.
> > > If you intend to make this a generic interface, please clean up the
> > > references to MediaTek and give it a more generic name. For example
> > > "Arm Trusted Firmware random number driver".
> > >
> > > It will also be helpful if the SMC call number is configurable.
> > >
> > > - Lars  
> >
> > Yes, I'm trying to make this to a generic interface. I'll try to make
> > HW/platform related dependency to be configurable and let it more
> > generic.
> > Thanks for your suggestion.
> >  
> 
> I don't think it makes sense for each arm64 platform to expose an
> entropy source via SMC calls in a slightly different way, and model it
> as a h/w driver. Instead, we should try to standardize this, and
> perhaps expose it via the architectural helpers that already exist
> (get_random_seed_long() and friends), so they get plugged into the
> kernel random pool driver directly.

Absolutely. I'd love to see a standard, ARM-specified, virtualizable
RNG that is abstracted from the HW.

> Note that in addition to drivers based on vendor SMC calls, we already
> have a RNG h/w driver based on OP-TEE as well, where the driver
> attaches to a standardized trusted OS interface identified by a UUID,
> and which also gets invoked via SMC calls into secure firmware.

... and probably an unhealthy number of hypervisor-specific hacks that
do the same thing. The sooner we plug this, the better.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-02 19:11         ` Marc Zyngier
@ 2019-12-03  4:16           ` Florian Fainelli
  2019-12-03 11:17             ` Marc Zyngier
  2019-12-03 10:17           ` Will Deacon
  1 sibling, 1 reply; 18+ messages in thread
From: Florian Fainelli @ 2019-12-03  4:16 UTC (permalink / raw)
  To: Marc Zyngier, Ard Biesheuvel, pawel.moll
  Cc: Mark Rutland, DTML, Herbert Xu, wsd_upstream, Catalin Marinas,
	Sean Wang, Linux Kernel Mailing List,
	Crystal Guo (郭晶),
	Rob Herring, linux-mediatek, linux-crypto, Matt Mackall,
	Matthias Brugger, Neal Liu, Will Deacon, Lars Persson,
	linux-arm-kernel



On 12/2/2019 11:11 AM, Marc Zyngier wrote:
> On Mon, 2 Dec 2019 16:12:09 +0000
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> 
>> (adding some more arm64 folks)
>>
>> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
>>>
>>> On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:  
>>>> Hi Neal,
>>>>
>>>> On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:  
>>>>>
>>>>> For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
>>>>> entropy sources is not accessible from normal world (linux) and
>>>>> rather accessible from secure world (ATF/TEE) only. This driver aims
>>>>> to provide a generic interface to ATF rng service.
>>>>>  
>>>>
>>>> I am working on several SoCs that also will need this kind of driver
>>>> to get entropy from Arm trusted firmware.
>>>> If you intend to make this a generic interface, please clean up the
>>>> references to MediaTek and give it a more generic name. For example
>>>> "Arm Trusted Firmware random number driver".
>>>>
>>>> It will also be helpful if the SMC call number is configurable.
>>>>
>>>> - Lars  
>>>
>>> Yes, I'm trying to make this to a generic interface. I'll try to make
>>> HW/platform related dependency to be configurable and let it more
>>> generic.
>>> Thanks for your suggestion.
>>>  
>>
>> I don't think it makes sense for each arm64 platform to expose an
>> entropy source via SMC calls in a slightly different way, and model it
>> as a h/w driver. Instead, we should try to standardize this, and
>> perhaps expose it via the architectural helpers that already exist
>> (get_random_seed_long() and friends), so they get plugged into the
>> kernel random pool driver directly.
> 
> Absolutely. I'd love to see a standard, ARM-specified, virtualizable
> RNG that is abstracted from the HW.

Do you think we could use virtio-rng on top of a modified virtio-mmio
which instead of being backed by a hardware mailbox, could use hvc/smc
calls to signal writes to shared memory and get notifications via an
interrupt? This would also open up the doors to other virtio uses cases
beyond just RNG (e.g.: console, block devices?). If this is completely
stupid, then please disregard this comment.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-02 19:11         ` Marc Zyngier
  2019-12-03  4:16           ` Florian Fainelli
@ 2019-12-03 10:17           ` Will Deacon
  1 sibling, 0 replies; 18+ messages in thread
From: Will Deacon @ 2019-12-03 10:17 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Mark Rutland, DTML, Herbert Xu, wsd_upstream, Ard Biesheuvel,
	Catalin Marinas, Sean Wang, linux-mediatek,
	Linux Kernel Mailing List, Rob Herring, Neal Liu, linux-crypto,
	Matt Mackall, Matthias Brugger, Crystal Guo (郭晶),
	Lars Persson, linux-arm-kernel

On Mon, Dec 02, 2019 at 07:11:46PM +0000, Marc Zyngier wrote:
> On Mon, 2 Dec 2019 16:12:09 +0000
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> 
> > (adding some more arm64 folks)
> > 
> > On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
> > >
> > > On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:  
> > > > Hi Neal,
> > > >
> > > > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:  
> > > > >
> > > > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > > > > entropy sources is not accessible from normal world (linux) and
> > > > > rather accessible from secure world (ATF/TEE) only. This driver aims
> > > > > to provide a generic interface to ATF rng service.
> > > > >  
> > > >
> > > > I am working on several SoCs that also will need this kind of driver
> > > > to get entropy from Arm trusted firmware.
> > > > If you intend to make this a generic interface, please clean up the
> > > > references to MediaTek and give it a more generic name. For example
> > > > "Arm Trusted Firmware random number driver".
> > > >
> > > > It will also be helpful if the SMC call number is configurable.
> > > >
> > > > - Lars  
> > >
> > > Yes, I'm trying to make this to a generic interface. I'll try to make
> > > HW/platform related dependency to be configurable and let it more
> > > generic.
> > > Thanks for your suggestion.
> > >  
> > 
> > I don't think it makes sense for each arm64 platform to expose an
> > entropy source via SMC calls in a slightly different way, and model it
> > as a h/w driver. Instead, we should try to standardize this, and
> > perhaps expose it via the architectural helpers that already exist
> > (get_random_seed_long() and friends), so they get plugged into the
> > kernel random pool driver directly.
> 
> Absolutely. I'd love to see a standard, ARM-specified, virtualizable
> RNG that is abstracted from the HW.

Same here. I hacked up some initial code for doing this with KVM [1], but
I'd much rather it was part of a standard service specification so that
we could use the same interface for talking to the firmware and the
hypervisor.

Will

[1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=kvm/hvc

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-03  4:16           ` Florian Fainelli
@ 2019-12-03 11:17             ` Marc Zyngier
  2019-12-12  5:13               ` Neal Liu
  0 siblings, 1 reply; 18+ messages in thread
From: Marc Zyngier @ 2019-12-03 11:17 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Mark Rutland, DTML, Herbert Xu, wsd_upstream, Ard Biesheuvel,
	Catalin Marinas, Sean Wang, Linux Kernel Mailing List,
	Matthias Brugger, Crystal Guo (郭晶),
	Rob Herring, pawel.moll, linux-crypto, Matt Mackall, Neal Liu,
	linux-mediatek, Will Deacon, Lars Persson, linux-arm-kernel

On 2019-12-03 04:16, Florian Fainelli wrote:
> On 12/2/2019 11:11 AM, Marc Zyngier wrote:
>> On Mon, 2 Dec 2019 16:12:09 +0000
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>
>>> (adding some more arm64 folks)
>>>
>>> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> 
>>> wrote:
>>>>
>>>> On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
>>>>> Hi Neal,
>>>>>
>>>>> On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> 
>>>>> wrote:
>>>>>>
>>>>>> For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals 
>>>>>> like
>>>>>> entropy sources is not accessible from normal world (linux) and
>>>>>> rather accessible from secure world (ATF/TEE) only. This driver 
>>>>>> aims
>>>>>> to provide a generic interface to ATF rng service.
>>>>>>
>>>>>
>>>>> I am working on several SoCs that also will need this kind of 
>>>>> driver
>>>>> to get entropy from Arm trusted firmware.
>>>>> If you intend to make this a generic interface, please clean up 
>>>>> the
>>>>> references to MediaTek and give it a more generic name. For 
>>>>> example
>>>>> "Arm Trusted Firmware random number driver".
>>>>>
>>>>> It will also be helpful if the SMC call number is configurable.
>>>>>
>>>>> - Lars
>>>>
>>>> Yes, I'm trying to make this to a generic interface. I'll try to 
>>>> make
>>>> HW/platform related dependency to be configurable and let it more
>>>> generic.
>>>> Thanks for your suggestion.
>>>>
>>>
>>> I don't think it makes sense for each arm64 platform to expose an
>>> entropy source via SMC calls in a slightly different way, and model 
>>> it
>>> as a h/w driver. Instead, we should try to standardize this, and
>>> perhaps expose it via the architectural helpers that already exist
>>> (get_random_seed_long() and friends), so they get plugged into the
>>> kernel random pool driver directly.
>>
>> Absolutely. I'd love to see a standard, ARM-specified, virtualizable
>> RNG that is abstracted from the HW.
>
> Do you think we could use virtio-rng on top of a modified virtio-mmio
> which instead of being backed by a hardware mailbox, could use 
> hvc/smc
> calls to signal writes to shared memory and get notifications via an
> interrupt? This would also open up the doors to other virtio uses 
> cases
> beyond just RNG (e.g.: console, block devices?). If this is 
> completely
> stupid, then please disregard this comment.

The problem with a virtio device is that it is a ... device. What we 
want
is to be able to have access to an entropy source extremely early in 
the
kernel life, and devices tend to be available pretty late in the game.
This means we cannot plug them in the architectural helpers that Ard
mentions above.

What you're suggesting looks more like a new kind of virtio transport,
which is interesting, in a remarkably twisted way... ;-)

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-03 11:17             ` Marc Zyngier
@ 2019-12-12  5:13               ` Neal Liu
  2019-12-12 11:45                 ` Marc Zyngier
  0 siblings, 1 reply; 18+ messages in thread
From: Neal Liu @ 2019-12-12  5:13 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Mark Rutland, DTML, Florian Fainelli, Herbert Xu, pawel.moll,
	Ard Biesheuvel, Catalin Marinas, Sean Wang,
	Linux Kernel Mailing List, wsd_upstream, Rob Herring,
	linux-mediatek, linux-crypto, Matt Mackall, Matthias Brugger,
	Crystal Guo (郭晶),
	Will Deacon, Lars Persson, linux-arm-kernel

On Tue, 2019-12-03 at 11:17 +0000, Marc Zyngier wrote:
> On 2019-12-03 04:16, Florian Fainelli wrote:
> > On 12/2/2019 11:11 AM, Marc Zyngier wrote:
> >> On Mon, 2 Dec 2019 16:12:09 +0000
> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >>
> >>> (adding some more arm64 folks)
> >>>
> >>> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> 
> >>> wrote:
> >>>>
> >>>> On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
> >>>>> Hi Neal,
> >>>>>
> >>>>> On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> 
> >>>>> wrote:
> >>>>>>
> >>>>>> For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals 
> >>>>>> like
> >>>>>> entropy sources is not accessible from normal world (linux) and
> >>>>>> rather accessible from secure world (ATF/TEE) only. This driver 
> >>>>>> aims
> >>>>>> to provide a generic interface to ATF rng service.
> >>>>>>
> >>>>>
> >>>>> I am working on several SoCs that also will need this kind of 
> >>>>> driver
> >>>>> to get entropy from Arm trusted firmware.
> >>>>> If you intend to make this a generic interface, please clean up 
> >>>>> the
> >>>>> references to MediaTek and give it a more generic name. For 
> >>>>> example
> >>>>> "Arm Trusted Firmware random number driver".
> >>>>>
> >>>>> It will also be helpful if the SMC call number is configurable.
> >>>>>
> >>>>> - Lars
> >>>>
> >>>> Yes, I'm trying to make this to a generic interface. I'll try to 
> >>>> make
> >>>> HW/platform related dependency to be configurable and let it more
> >>>> generic.
> >>>> Thanks for your suggestion.
> >>>>
> >>>
> >>> I don't think it makes sense for each arm64 platform to expose an
> >>> entropy source via SMC calls in a slightly different way, and model 
> >>> it
> >>> as a h/w driver. Instead, we should try to standardize this, and
> >>> perhaps expose it via the architectural helpers that already exist
> >>> (get_random_seed_long() and friends), so they get plugged into the
> >>> kernel random pool driver directly.
> >>
> >> Absolutely. I'd love to see a standard, ARM-specified, virtualizable
> >> RNG that is abstracted from the HW.
> >
> > Do you think we could use virtio-rng on top of a modified virtio-mmio
> > which instead of being backed by a hardware mailbox, could use 
> > hvc/smc
> > calls to signal writes to shared memory and get notifications via an
> > interrupt? This would also open up the doors to other virtio uses 
> > cases
> > beyond just RNG (e.g.: console, block devices?). If this is 
> > completely
> > stupid, then please disregard this comment.
> 
> The problem with a virtio device is that it is a ... device. What we 
> want
> is to be able to have access to an entropy source extremely early in 
> the
> kernel life, and devices tend to be available pretty late in the game.
> This means we cannot plug them in the architectural helpers that Ard
> mentions above.
> 
> What you're suggesting looks more like a new kind of virtio transport,
> which is interesting, in a remarkably twisted way... ;-)
> 
> Thanks,
> 
>          M.

In conclusion, is it helpful that hw_random has a generic interface to
add device randomness by talking to hwrng which is implemented in the
firmware or the hypervisor?
For most chip vendors, I think the answer is yes. We already prepared a
new patchset and need you agree with this idea.

Thanks

-Neal

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-12  5:13               ` Neal Liu
@ 2019-12-12 11:45                 ` Marc Zyngier
  2019-12-12 14:03                   ` Ard Biesheuvel
  0 siblings, 1 reply; 18+ messages in thread
From: Marc Zyngier @ 2019-12-12 11:45 UTC (permalink / raw)
  To: Neal Liu
  Cc: Mark Rutland, DTML, Florian Fainelli, Herbert Xu, pawel.moll,
	Ard Biesheuvel, Catalin Marinas, Sean Wang,
	Linux Kernel Mailing List, wsd_upstream, Rob Herring,
	linux-mediatek, linux-crypto, Matt Mackall, Matthias Brugger,
	Crystal Guo (郭晶),
	Will Deacon, Lars Persson, linux-arm-kernel

On 2019-12-12 05:13, Neal Liu wrote:
> On Tue, 2019-12-03 at 11:17 +0000, Marc Zyngier wrote:
>> On 2019-12-03 04:16, Florian Fainelli wrote:
>> > On 12/2/2019 11:11 AM, Marc Zyngier wrote:
>> >> On Mon, 2 Dec 2019 16:12:09 +0000
>> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >>
>> >>> (adding some more arm64 folks)
>> >>>
>> >>> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com>
>> >>> wrote:
>> >>>>
>> >>>> On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
>> >>>>> Hi Neal,
>> >>>>>
>> >>>>> On Wed, Nov 27, 2019 at 3:23 PM Neal Liu 
>> <neal.liu@mediatek.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> For MediaTek SoCs on ARMv8 with TrustZone enabled, 
>> peripherals
>> >>>>>> like
>> >>>>>> entropy sources is not accessible from normal world (linux) 
>> and
>> >>>>>> rather accessible from secure world (ATF/TEE) only. This 
>> driver
>> >>>>>> aims
>> >>>>>> to provide a generic interface to ATF rng service.
>> >>>>>>
>> >>>>>
>> >>>>> I am working on several SoCs that also will need this kind of
>> >>>>> driver
>> >>>>> to get entropy from Arm trusted firmware.
>> >>>>> If you intend to make this a generic interface, please clean 
>> up
>> >>>>> the
>> >>>>> references to MediaTek and give it a more generic name. For
>> >>>>> example
>> >>>>> "Arm Trusted Firmware random number driver".
>> >>>>>
>> >>>>> It will also be helpful if the SMC call number is 
>> configurable.
>> >>>>>
>> >>>>> - Lars
>> >>>>
>> >>>> Yes, I'm trying to make this to a generic interface. I'll try 
>> to
>> >>>> make
>> >>>> HW/platform related dependency to be configurable and let it 
>> more
>> >>>> generic.
>> >>>> Thanks for your suggestion.
>> >>>>
>> >>>
>> >>> I don't think it makes sense for each arm64 platform to expose 
>> an
>> >>> entropy source via SMC calls in a slightly different way, and 
>> model
>> >>> it
>> >>> as a h/w driver. Instead, we should try to standardize this, and
>> >>> perhaps expose it via the architectural helpers that already 
>> exist
>> >>> (get_random_seed_long() and friends), so they get plugged into 
>> the
>> >>> kernel random pool driver directly.
>> >>
>> >> Absolutely. I'd love to see a standard, ARM-specified, 
>> virtualizable
>> >> RNG that is abstracted from the HW.
>> >
>> > Do you think we could use virtio-rng on top of a modified 
>> virtio-mmio
>> > which instead of being backed by a hardware mailbox, could use
>> > hvc/smc
>> > calls to signal writes to shared memory and get notifications via 
>> an
>> > interrupt? This would also open up the doors to other virtio uses
>> > cases
>> > beyond just RNG (e.g.: console, block devices?). If this is
>> > completely
>> > stupid, then please disregard this comment.
>>
>> The problem with a virtio device is that it is a ... device. What we
>> want
>> is to be able to have access to an entropy source extremely early in
>> the
>> kernel life, and devices tend to be available pretty late in the 
>> game.
>> This means we cannot plug them in the architectural helpers that Ard
>> mentions above.
>>
>> What you're suggesting looks more like a new kind of virtio 
>> transport,
>> which is interesting, in a remarkably twisted way... ;-)
>>
>> Thanks,
>>
>>          M.
>
> In conclusion, is it helpful that hw_random has a generic interface 
> to
> add device randomness by talking to hwrng which is implemented in the
> firmware or the hypervisor?
> For most chip vendors, I think the answer is yes. We already prepared 
> a
> new patchset and need you agree with this idea.

As long as it is a *unified* interface, I'm all for that.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-12 11:45                 ` Marc Zyngier
@ 2019-12-12 14:03                   ` Ard Biesheuvel
  2019-12-12 14:30                     ` Marc Zyngier
  0 siblings, 1 reply; 18+ messages in thread
From: Ard Biesheuvel @ 2019-12-12 14:03 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Mark Rutland, DTML, Florian Fainelli, Herbert Xu, Pawel Moll,
	Catalin Marinas, Sean Wang, Linux Kernel Mailing List,
	wsd_upstream, Crystal Guo (郭晶),
	Rob Herring, Neal Liu,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Matt Mackall,
	Matthias Brugger, moderated list:ARM/Mediatek SoC support,
	Will Deacon, Lars Persson, linux-arm-kernel

On Thu, 12 Dec 2019 at 12:45, Marc Zyngier <maz@kernel.org> wrote:
>
> On 2019-12-12 05:13, Neal Liu wrote:
> > On Tue, 2019-12-03 at 11:17 +0000, Marc Zyngier wrote:
> >> On 2019-12-03 04:16, Florian Fainelli wrote:
> >> > On 12/2/2019 11:11 AM, Marc Zyngier wrote:
> >> >> On Mon, 2 Dec 2019 16:12:09 +0000
> >> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> >>
> >> >>> (adding some more arm64 folks)
> >> >>>
> >> >>> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com>
> >> >>> wrote:
> >> >>>>
> >> >>>> On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
> >> >>>>> Hi Neal,
> >> >>>>>
> >> >>>>> On Wed, Nov 27, 2019 at 3:23 PM Neal Liu
> >> <neal.liu@mediatek.com>
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>> For MediaTek SoCs on ARMv8 with TrustZone enabled,
> >> peripherals
> >> >>>>>> like
> >> >>>>>> entropy sources is not accessible from normal world (linux)
> >> and
> >> >>>>>> rather accessible from secure world (ATF/TEE) only. This
> >> driver
> >> >>>>>> aims
> >> >>>>>> to provide a generic interface to ATF rng service.
> >> >>>>>>
> >> >>>>>
> >> >>>>> I am working on several SoCs that also will need this kind of
> >> >>>>> driver
> >> >>>>> to get entropy from Arm trusted firmware.
> >> >>>>> If you intend to make this a generic interface, please clean
> >> up
> >> >>>>> the
> >> >>>>> references to MediaTek and give it a more generic name. For
> >> >>>>> example
> >> >>>>> "Arm Trusted Firmware random number driver".
> >> >>>>>
> >> >>>>> It will also be helpful if the SMC call number is
> >> configurable.
> >> >>>>>
> >> >>>>> - Lars
> >> >>>>
> >> >>>> Yes, I'm trying to make this to a generic interface. I'll try
> >> to
> >> >>>> make
> >> >>>> HW/platform related dependency to be configurable and let it
> >> more
> >> >>>> generic.
> >> >>>> Thanks for your suggestion.
> >> >>>>
> >> >>>
> >> >>> I don't think it makes sense for each arm64 platform to expose
> >> an
> >> >>> entropy source via SMC calls in a slightly different way, and
> >> model
> >> >>> it
> >> >>> as a h/w driver. Instead, we should try to standardize this, and
> >> >>> perhaps expose it via the architectural helpers that already
> >> exist
> >> >>> (get_random_seed_long() and friends), so they get plugged into
> >> the
> >> >>> kernel random pool driver directly.
> >> >>
> >> >> Absolutely. I'd love to see a standard, ARM-specified,
> >> virtualizable
> >> >> RNG that is abstracted from the HW.
> >> >
> >> > Do you think we could use virtio-rng on top of a modified
> >> virtio-mmio
> >> > which instead of being backed by a hardware mailbox, could use
> >> > hvc/smc
> >> > calls to signal writes to shared memory and get notifications via
> >> an
> >> > interrupt? This would also open up the doors to other virtio uses
> >> > cases
> >> > beyond just RNG (e.g.: console, block devices?). If this is
> >> > completely
> >> > stupid, then please disregard this comment.
> >>
> >> The problem with a virtio device is that it is a ... device. What we
> >> want
> >> is to be able to have access to an entropy source extremely early in
> >> the
> >> kernel life, and devices tend to be available pretty late in the
> >> game.
> >> This means we cannot plug them in the architectural helpers that Ard
> >> mentions above.
> >>
> >> What you're suggesting looks more like a new kind of virtio
> >> transport,
> >> which is interesting, in a remarkably twisted way... ;-)
> >>
> >> Thanks,
> >>
> >>          M.
> >
> > In conclusion, is it helpful that hw_random has a generic interface
> > to
> > add device randomness by talking to hwrng which is implemented in the
> > firmware or the hypervisor?
> > For most chip vendors, I think the answer is yes. We already prepared
> > a
> > new patchset and need you agree with this idea.
>
> As long as it is a *unified* interface, I'm all for that.
>


Yeah, but I'm not sure it makes sense to model it as a device like
this. It would be nice if we could tie this into the ARM SMCCC
discovery, and use the SMC calls to back arch_get_random_seed_long()
[provided we fix the braindead way in which that is being used today
in the interrupt code]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-12 14:03                   ` Ard Biesheuvel
@ 2019-12-12 14:30                     ` Marc Zyngier
  0 siblings, 0 replies; 18+ messages in thread
From: Marc Zyngier @ 2019-12-12 14:30 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Mark Rutland, DTML, Florian Fainelli, Herbert Xu, Pawel Moll,
	Catalin Marinas, Sean Wang, Linux Kernel Mailing List,
	wsd_upstream, Crystal Guo (郭晶),
	Rob Herring, Neal Liu,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Matt Mackall,
	Matthias Brugger, moderated list:ARM/Mediatek SoC support,
	Will Deacon, Lars Persson, linux-arm-kernel

On 2019-12-12 14:03, Ard Biesheuvel wrote:
> On Thu, 12 Dec 2019 at 12:45, Marc Zyngier <maz@kernel.org> wrote:
>>
>> On 2019-12-12 05:13, Neal Liu wrote:
>> > On Tue, 2019-12-03 at 11:17 +0000, Marc Zyngier wrote:
>> >> On 2019-12-03 04:16, Florian Fainelli wrote:
>> >> > On 12/2/2019 11:11 AM, Marc Zyngier wrote:
>> >> >> On Mon, 2 Dec 2019 16:12:09 +0000
>> >> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >> >>
>> >> >>> (adding some more arm64 folks)
>> >> >>>
>> >> >>> On Fri, 29 Nov 2019 at 11:30, Neal Liu 
>> <neal.liu@mediatek.com>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
>> >> >>>>> Hi Neal,
>> >> >>>>>
>> >> >>>>> On Wed, Nov 27, 2019 at 3:23 PM Neal Liu
>> >> <neal.liu@mediatek.com>
>> >> >>>>> wrote:
>> >> >>>>>>
>> >> >>>>>> For MediaTek SoCs on ARMv8 with TrustZone enabled,
>> >> peripherals
>> >> >>>>>> like
>> >> >>>>>> entropy sources is not accessible from normal world 
>> (linux)
>> >> and
>> >> >>>>>> rather accessible from secure world (ATF/TEE) only. This
>> >> driver
>> >> >>>>>> aims
>> >> >>>>>> to provide a generic interface to ATF rng service.
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>> I am working on several SoCs that also will need this kind 
>> of
>> >> >>>>> driver
>> >> >>>>> to get entropy from Arm trusted firmware.
>> >> >>>>> If you intend to make this a generic interface, please 
>> clean
>> >> up
>> >> >>>>> the
>> >> >>>>> references to MediaTek and give it a more generic name. For
>> >> >>>>> example
>> >> >>>>> "Arm Trusted Firmware random number driver".
>> >> >>>>>
>> >> >>>>> It will also be helpful if the SMC call number is
>> >> configurable.
>> >> >>>>>
>> >> >>>>> - Lars
>> >> >>>>
>> >> >>>> Yes, I'm trying to make this to a generic interface. I'll 
>> try
>> >> to
>> >> >>>> make
>> >> >>>> HW/platform related dependency to be configurable and let it
>> >> more
>> >> >>>> generic.
>> >> >>>> Thanks for your suggestion.
>> >> >>>>
>> >> >>>
>> >> >>> I don't think it makes sense for each arm64 platform to 
>> expose
>> >> an
>> >> >>> entropy source via SMC calls in a slightly different way, and
>> >> model
>> >> >>> it
>> >> >>> as a h/w driver. Instead, we should try to standardize this, 
>> and
>> >> >>> perhaps expose it via the architectural helpers that already
>> >> exist
>> >> >>> (get_random_seed_long() and friends), so they get plugged 
>> into
>> >> the
>> >> >>> kernel random pool driver directly.
>> >> >>
>> >> >> Absolutely. I'd love to see a standard, ARM-specified,
>> >> virtualizable
>> >> >> RNG that is abstracted from the HW.
>> >> >
>> >> > Do you think we could use virtio-rng on top of a modified
>> >> virtio-mmio
>> >> > which instead of being backed by a hardware mailbox, could use
>> >> > hvc/smc
>> >> > calls to signal writes to shared memory and get notifications 
>> via
>> >> an
>> >> > interrupt? This would also open up the doors to other virtio 
>> uses
>> >> > cases
>> >> > beyond just RNG (e.g.: console, block devices?). If this is
>> >> > completely
>> >> > stupid, then please disregard this comment.
>> >>
>> >> The problem with a virtio device is that it is a ... device. What 
>> we
>> >> want
>> >> is to be able to have access to an entropy source extremely early 
>> in
>> >> the
>> >> kernel life, and devices tend to be available pretty late in the
>> >> game.
>> >> This means we cannot plug them in the architectural helpers that 
>> Ard
>> >> mentions above.
>> >>
>> >> What you're suggesting looks more like a new kind of virtio
>> >> transport,
>> >> which is interesting, in a remarkably twisted way... ;-)
>> >>
>> >> Thanks,
>> >>
>> >>          M.
>> >
>> > In conclusion, is it helpful that hw_random has a generic 
>> interface
>> > to
>> > add device randomness by talking to hwrng which is implemented in 
>> the
>> > firmware or the hypervisor?
>> > For most chip vendors, I think the answer is yes. We already 
>> prepared
>> > a
>> > new patchset and need you agree with this idea.
>>
>> As long as it is a *unified* interface, I'm all for that.
>>
>
>
> Yeah, but I'm not sure it makes sense to model it as a device like
> this. It would be nice if we could tie this into the ARM SMCCC
> discovery, and use the SMC calls to back arch_get_random_seed_long()

Probably I wasn't clear enough, but that's really what I meant by
a unified interface (implemented by the firmware or the hypervisor).

> [provided we fix the braindead way in which that is being used today
> in the interrupt code]

Ah, I said I'd look into it. Thanks for the reminder...

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
  2019-12-02 16:12       ` Ard Biesheuvel
  2019-12-02 19:11         ` Marc Zyngier
@ 2019-12-12 14:43         ` Sudeep Holla
  1 sibling, 0 replies; 18+ messages in thread
From: Sudeep Holla @ 2019-12-12 14:43 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Mark Rutland, DTML, Sudeep Holla, Herbert Xu, wsd_upstream,
	Catalin Marinas, Matt Mackall, Sean Wang, linux-mediatek,
	Linux Kernel Mailing List, Rob Herring, Neal Liu, linux-crypto,
	Marc Zyngier, Matthias Brugger, Crystal Guo (郭晶),
	Will Deacon, Lars Persson, linux-arm-kernel

On Mon, Dec 02, 2019 at 04:12:09PM +0000, Ard Biesheuvel wrote:
> (adding some more arm64 folks)
> 
> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
> >
> > On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:
> > > Hi Neal,
> > >
> > > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:
> > > >
> > > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > > > entropy sources is not accessible from normal world (linux) and
> > > > rather accessible from secure world (ATF/TEE) only. This driver aims
> > > > to provide a generic interface to ATF rng service.
> > > >
> > >
> > > I am working on several SoCs that also will need this kind of driver
> > > to get entropy from Arm trusted firmware.
> > > If you intend to make this a generic interface, please clean up the
> > > references to MediaTek and give it a more generic name. For example
> > > "Arm Trusted Firmware random number driver".
> > >
> > > It will also be helpful if the SMC call number is configurable.
> > >
> > > - Lars
> >
> > Yes, I'm trying to make this to a generic interface. I'll try to make
> > HW/platform related dependency to be configurable and let it more
> > generic.
> > Thanks for your suggestion.
> >
> 
> I don't think it makes sense for each arm64 platform to expose an
> entropy source via SMC calls in a slightly different way, and model it
> as a h/w driver. Instead, we should try to standardize this, and
> perhaps expose it via the architectural helpers that already exist
> (get_random_seed_long() and friends), so they get plugged into the
> kernel random pool driver directly.
> 
> Note that in addition to drivers based on vendor SMC calls, we already
> have a RNG h/w driver based on OP-TEE as well, where the driver
> attaches to a standardized trusted OS interface identified by a UUID,
> and which also gets invoked via SMC calls into secure firmware.

Yes, I agree. I had raised the issue internally and forgot to follow up.
I raised this few months back after I read a blog[1]

--
Regards,
Sudeep

[1] https://community.arm.com/developer/ip-products/processors/f/cortex-a-forum/43679/arm-really-should-standardize-an-smc-interface-for-hardware-random-number-generators

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2019-12-12 14:44 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-27 14:22 [PATCH v5 0/3] MediaTek Security random number generator support Neal Liu
2019-11-27 14:22 ` [PATCH v5 1/3] soc: mediatek: add SMC fid table for SIP interface Neal Liu
2019-11-27 14:22 ` [PATCH v5 2/3] dt-bindings: rng: add bindings for MediaTek ARMv8 SoCs Neal Liu
2019-11-27 14:22 ` [PATCH v5 3/3] hwrng: add mtk-sec-rng driver Neal Liu
2019-11-27 15:03   ` Ard Biesheuvel
2019-11-28 15:02     ` Neal Liu
2019-11-29 10:02   ` Lars Persson
2019-11-29 11:30     ` Neal Liu
2019-12-02 16:12       ` Ard Biesheuvel
2019-12-02 19:11         ` Marc Zyngier
2019-12-03  4:16           ` Florian Fainelli
2019-12-03 11:17             ` Marc Zyngier
2019-12-12  5:13               ` Neal Liu
2019-12-12 11:45                 ` Marc Zyngier
2019-12-12 14:03                   ` Ard Biesheuvel
2019-12-12 14:30                     ` Marc Zyngier
2019-12-03 10:17           ` Will Deacon
2019-12-12 14:43         ` Sudeep Holla

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).