[PATCH 0/3] Add support for Graviton TRNG

[PATCH 0/3] Add support for Graviton TRNG

[Ali Saidi]

AWS Graviton based systems provide an Arm SMC call in the vendor defined
hypervisor region to read random numbers from a HW TRNG and return them to the
guest. 

We've observed slower guest boot and especially reboot times due to lack of
entropy and providing access to a TRNG is meant to address this. 

Ali Saidi (3):
  arm/arm64: Add smccc hypervisor service identifiers
  arm64: export acpi_psci_use_hvc
  hwrng: Add support for AWS Graviton TRNG

 MAINTAINERS                           |   6 ++
 arch/arm64/kernel/acpi.c              |   1 +
 drivers/char/hw_random/Kconfig        |  13 ++++
 drivers/char/hw_random/Makefile       |   1 +
 drivers/char/hw_random/graviton-rng.c | 123 ++++++++++++++++++++++++++++++++++
 include/linux/arm-smccc.h             |   2 +
 6 files changed, 146 insertions(+)
 create mode 100644 drivers/char/hw_random/graviton-rng.c

-- 
2.15.3.AMZN

[PATCH 1/3] arm/arm64: Add smccc hypervisor service identifiers

[Ali Saidi]

The SMC calling convention defines service identifiers for generic and
vendor specific hypervisor services. This patch adds those services to
the list of existing service identifiers.

Signed-off-by: Ali Saidi <alisaidi@amazon.com>
---
 include/linux/arm-smccc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 18863d56273c..bcf796801e3b 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -54,6 +54,8 @@
 #define ARM_SMCCC_OWNER_SIP		2
 #define ARM_SMCCC_OWNER_OEM		3
 #define ARM_SMCCC_OWNER_STANDARD	4
+#define ARM_SMCCC_OWNER_STANDARD_HV	5
+#define ARM_SMCCC_OWNER_VENDOR_HV	6
 #define ARM_SMCCC_OWNER_TRUSTED_APP	48
 #define ARM_SMCCC_OWNER_TRUSTED_APP_END	49
 #define ARM_SMCCC_OWNER_TRUSTED_OS	50
-- 
2.15.3.AMZN

[PATCH 2/3] arm64: export acpi_psci_use_hvc

[Ali Saidi]

Allow a module that wants to make SMC calls to detect if it should be
using smc or hvc.

Signed-off-by: Ali Saidi <alisaidi@amazon.com>
---
 arch/arm64/kernel/acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 803f0494dd3e..ea41c6541d3c 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
 {
 	return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
 }
+EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
 
 /*
  * acpi_fadt_sanity_check() - Check FADT presence and carry out sanity
-- 
2.15.3.AMZN

Re: [PATCH 2/3] arm64: export acpi_psci_use_hvc

[Sudeep Holla]

On Tue, Jun 04, 2019 at 08:30:59PM +0000, Ali Saidi wrote:
> Allow a module that wants to make SMC calls to detect if it should be
> using smc or hvc.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> ---
>  arch/arm64/kernel/acpi.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 803f0494dd3e..ea41c6541d3c 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
>  {
>  	return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
>  }
> +EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
>

I would rather have this in drivers/firmware/psci/psci.c checking the
value of psci_ops.conduit so that it's not just ACPI specific and can
be used on DT platforms too if required.

--
Regards,
Sudeep

Re: [PATCH 2/3] arm64: export acpi_psci_use_hvc

[Mark Rutland]

On Wed, Jun 05, 2019 at 10:40:31AM +0100, Sudeep Holla wrote:
> On Tue, Jun 04, 2019 at 08:30:59PM +0000, Ali Saidi wrote:
> > Allow a module that wants to make SMC calls to detect if it should be
> > using smc or hvc.
> >
> > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > ---
> >  arch/arm64/kernel/acpi.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index 803f0494dd3e..ea41c6541d3c 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
> >  {
> >  	return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> >  }
> > +EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
> >
> 
> I would rather have this in drivers/firmware/psci/psci.c checking the
> value of psci_ops.conduit so that it's not just ACPI specific and can
> be used on DT platforms too if required.

I'd also like this to not hook into PSCI internals. This code cares
about SMCCC, not PSCI. We also really shouldn't need to spread the
conduit management everywhere, too. We should be abel to have probe code
do:

	if (!is_smccc_1_1_available())
		goto fail_probe;

... and runtime code do:

	res = arm_smccc_1_1_call(...);

... which is much clearner.

I'd started cleaning that up [1], but I haven't had the chance to rebase
and repost it.

Ali, I assume your firmware has SMCCCv1.1+. Is that the case?

Thanks,
Mark.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/smccc-cleanup

Re: [PATCH 2/3] arm64: export acpi_psci_use_hvc

[Sudeep Holla]

On Wed, Jun 05, 2019 at 11:38:40AM +0100, Mark Rutland wrote:
> On Wed, Jun 05, 2019 at 10:40:31AM +0100, Sudeep Holla wrote:
> > On Tue, Jun 04, 2019 at 08:30:59PM +0000, Ali Saidi wrote:
> > > Allow a module that wants to make SMC calls to detect if it should be
> > > using smc or hvc.
> > >
> > > Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> > > ---
> > >  arch/arm64/kernel/acpi.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > > index 803f0494dd3e..ea41c6541d3c 100644
> > > --- a/arch/arm64/kernel/acpi.c
> > > +++ b/arch/arm64/kernel/acpi.c
> > > @@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
> > >  {
> > >  	return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> > >  }
> > > +EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
> > >
> > 
> > I would rather have this in drivers/firmware/psci/psci.c checking the
> > value of psci_ops.conduit so that it's not just ACPI specific and can
> > be used on DT platforms too if required.
> 
> I'd also like this to not hook into PSCI internals. This code cares
> about SMCCC, not PSCI. We also really shouldn't need to spread the
> conduit management everywhere, too.

I agree. I remember suggesting the same to Xilinx a while ago but I
didn't see your patches in the mainline.

--
Regards,
Sudeep

Re: [PATCH 2/3] arm64: export acpi_psci_use_hvc

[Saidi, Ali]

On 6/5/19, 5:40 AM, "Mark Rutland" <mark.rutland@arm.com> wrote:

    Ali, I assume your firmware has SMCCCv1.1+. Is that the case?
    

Yes, it does. I'm happy to be able to call a generic function instead of having to figure out which conduit to use.

Ali

    

[PATCH 3/3] hwrng: Add support for AWS Graviton TRNG

[Ali Saidi]

AWS Graviton based systems provide an Arm SMC call in the vendor defined
hypervisor region to read random numbers from a TRNG and return them
to the guest.

Co-developed-by: Ron Rindjunsky <ronrindj@amazon.com>
Signed-off-by: Ali Saidi <alisaidi@amazon.com>
Signed-off-by: Ron Rindjunsky <ronrindj@amazon.com>

---
 MAINTAINERS                           |   6 ++
 drivers/char/hw_random/Kconfig        |  13 ++++
 drivers/char/hw_random/Makefile       |   1 +
 drivers/char/hw_random/graviton-rng.c | 130 ++++++++++++++++++++++++++++++++++
 4 files changed, 150 insertions(+)
 create mode 100644 drivers/char/hw_random/graviton-rng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 005902ea1450..e9c490e3fd9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2771,6 +2771,12 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
 F:	drivers/iio/adc/hx711.c
 
+AWS GRAVITON TRNG DRIVER
+M:	Ali Saidi <alisaidi@amazon.com>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Supported
+F:	drivers/char/hw_random/graviton-rng.c
+
 AX.25 NETWORK LAYER
 M:	Ralf Baechle <ralf@linux-mips.org>
 L:	linux-hams@vger.kernel.org
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 25a7d8ffdb5d..7ca7386a1ac4 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -439,6 +439,19 @@ config HW_RANDOM_OPTEE
 
 	  If unsure, say Y.
 
+config HW_RANDOM_GRAVITON
+	tristate "AWS Graviton Random Number Generator support"
+	depends on HW_RANDOM && ACPI && (ARM64 || COMPILE_TEST)
+	default HW_RANDOM
+	help
+	  This driver provides kernel-side support for the Random Number
+	  Generator SMC found on AWS Graviton systems.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called graviton-rng.
+
+	  If unsure, say Y.
+
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 7c9ef4a7667f..d1fa72670e98 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_HW_RANDOM_MTK)	+= mtk-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
+obj-$(CONFIG_HW_RANDOM_GRAVITON) += graviton-rng.o
diff --git a/drivers/char/hw_random/graviton-rng.c b/drivers/char/hw_random/graviton-rng.c
new file mode 100644
index 000000000000..898c8bb98a20
--- /dev/null
+++ b/drivers/char/hw_random/graviton-rng.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AWS Graviton TRNG driver
+ *
+ * Copyright (C) 2019 Amazon Corp.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/arm-smccc.h>
+#include <linux/device.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/acpi.h>
+#include <linux/psci.h>
+#include <linux/module.h>
+
+#define AWS_GRAVITON_UUID \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_VENDOR_HV, 0xFF01)
+#define AWS_GRAVITON_GET_VER \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_VENDOR_HV, 0xFF03)
+#define AWS_GRAVITON_GET_RND \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
+			   ARM_SMCCC_OWNER_VENDOR_HV, 0)
+
+/**
+ *  UID of the Graviton TRNG API: 1b64036c-badc-483e-99d23e283f067bdd
+ */
+#define GRVTN_TRNG_UUID_0		0x6c03641b
+#define GRVTN_TRNG_UUID_1		0x3e48dcba
+#define GRVTN_TRNG_UUID_2		0x283ed299
+#define GRVTN_TRNG_UUID_3		0xdd7b063f
+
+static void grvtn_smccc_conduit(u64 call_id, struct arm_smccc_res *res)
+{
+	if (acpi_psci_use_hvc())
+		arm_smccc_1_1_hvc(call_id, res);
+	else
+		arm_smccc_1_1_smc(call_id, res);
+}
+
+static int grvtn_trng_read(struct hwrng *trng, void *buf, size_t max, bool wait)
+{
+	struct arm_smccc_res res;
+	int err = 0;
+	/* timeout after one waiting period */
+	int iter_remain = 2;
+	size_t count = max > sizeof(ulong) * 2 ? sizeof(ulong) * 2 : max;
+	size_t total = count;
+
+	do {
+		if (err && wait)
+			/* Nominal wait is 5us */
+			udelay(err);
+
+		grvtn_smccc_conduit(AWS_GRAVITON_GET_RND, &res);
+		err = (int) res.a0;
+
+		if (err < 0)
+			return err;
+
+		iter_remain--;
+	} while (iter_remain && err && wait);
+
+	if (err)
+		return 0;
+
+	if (count > sizeof(ulong)) {
+		memcpy(buf, &res.a1, sizeof(ulong));
+		count -= sizeof(ulong);
+		buf += sizeof(ulong);
+	}
+	memcpy(buf, &res.a2, count);
+	return total;
+}
+
+static int grvtn_trng_probe(struct platform_device *pdev)
+{
+	int err;
+	struct arm_smccc_res res;
+	static struct hwrng ops = {
+		.name = "graviton",
+		.read = grvtn_trng_read,
+		.quality = 1024, /* all bits are sourced from a HW TRNG */
+	};
+
+	grvtn_smccc_conduit(AWS_GRAVITON_UUID, &res);
+
+	if (res.a0 != GRVTN_TRNG_UUID_0 || res.a1 != GRVTN_TRNG_UUID_1 ||
+	    res.a2 != GRVTN_TRNG_UUID_2 || res.a3 != GRVTN_TRNG_UUID_3) {
+		dev_err(&pdev->dev, "failed to match UUID\n");
+		return -ENXIO;
+	}
+
+	grvtn_smccc_conduit(AWS_GRAVITON_GET_VER, &res);
+	dev_info(&pdev->dev, "Graviton TRNG, SMC version %d.%d\n",
+		(u32)res.a0, (u32)res.a1);
+
+	platform_set_drvdata(pdev, &ops);
+	err = devm_hwrng_register(&pdev->dev, &ops);
+	if (err)
+		dev_err(&pdev->dev, "failed to register hwrng");
+	return err;
+}
+
+static const struct acpi_device_id grvtn_trng_acpi_match[] = {
+	{ "AMZN0010", },
+	{}
+};
+
+MODULE_DEVICE_TABLE(acpi, grvtn_trng_acpi_match);
+
+static struct platform_driver grvtn_trng_driver = {
+	.probe  = grvtn_trng_probe,
+	.driver = {
+		.name = "graviton-rng",
+		.owner = THIS_MODULE,
+		.acpi_match_table = ACPI_PTR(grvtn_trng_acpi_match),
+	},
+};
+
+module_platform_driver(grvtn_trng_driver);
+
+MODULE_AUTHOR("Amazon.com, Inc. or it's affiliates");
+MODULE_DESCRIPTION("Graviton TRNG driver");
+MODULE_LICENSE("GPL v2");
-- 
2.15.3.AMZN

Re: [PATCH 0/3] Add support for Graviton TRNG

[Will Deacon]

On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
> AWS Graviton based systems provide an Arm SMC call in the vendor defined
> hypervisor region to read random numbers from a HW TRNG and return them to the
> guest. 
> 
> We've observed slower guest boot and especially reboot times due to lack of
> entropy and providing access to a TRNG is meant to address this. 

Curious, but why this over something like virtio-rng?

Will

Re: [PATCH 0/3] Add support for Graviton TRNG

[Saidi, Ali]

On 6/5/19, 7:20 AM, "Will Deacon" <will.deacon@arm.com> wrote:

    On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
    > AWS Graviton based systems provide an Arm SMC call in the vendor defined
    > hypervisor region to read random numbers from a HW TRNG and return them to the
    > guest. 
    > 
    > We've observed slower guest boot and especially reboot times due to lack of
    > entropy and providing access to a TRNG is meant to address this. 
    
    Curious, but why this over something like virtio-rng?
    
This interface allows us to provide the functionality from both EL2 and EL3 and support multiple different types of our instances which we unfortunately can't do with virt-io.

Ali
    

Re: [PATCH 0/3] Add support for Graviton TRNG

[Saidi, Ali]

On 6/7/19, 7:59 AM, " Ali Saidi" <alisaidi@amazon.com> wrote:

    
    
    On 6/5/19, 7:20 AM, "Will Deacon" <will.deacon@arm.com> wrote:
    
        On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
        > AWS Graviton based systems provide an Arm SMC call in the vendor defined
        > hypervisor region to read random numbers from a HW TRNG and return them to the
        > guest. 
        > 
        > We've observed slower guest boot and especially reboot times due to lack of
        > entropy and providing access to a TRNG is meant to address this. 
        
        Curious, but why this over something like virtio-rng?
        
    This interface allows us to provide the functionality from both EL2 and EL3 and support multiple different types of our instances which we unfortunately can't do with virt-io.
    
Will,

Any additional comments?

Mark,

Do you know when you'll have a chance to rebase arm64/smccc-cleanup?

Thanks,
Ali

Re: [PATCH 0/3] Add support for Graviton TRNG

[Will Deacon]

[Note: this was in my spam folder]

On Fri, Jun 28, 2019 at 06:05:10PM +0000, Saidi, Ali wrote:
> On 6/7/19, 7:59 AM, " Ali Saidi" <alisaidi@amazon.com> wrote:
>     On 6/5/19, 7:20 AM, "Will Deacon" <will.deacon@arm.com> wrote:
>         On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
>         > AWS Graviton based systems provide an Arm SMC call in the vendor defined
>         > hypervisor region to read random numbers from a HW TRNG and return them to the
>         > guest. 
>         > 
>         > We've observed slower guest boot and especially reboot times due to lack of
>         > entropy and providing access to a TRNG is meant to address this. 
>         
>         Curious, but why this over something like virtio-rng?
>         
>     This interface allows us to provide the functionality from both EL2
>     and EL3 and support multiple different types of our instances which we
>     unfortunately can't do with virt-io.
>     
> Any additional comments?
> Do you know when you'll have a chance to rebase arm64/smccc-cleanup?

Sorry, Ali, this slipped through the cracks. Marc and I will chat today and
look at respinning what we had before; it should then hopefully be
straightforward enough for you to take that as a base for what you want to
do.

Will

Re: [PATCH 0/3] Add support for Graviton TRNG

[Will Deacon]

[+Marc]

On Mon, Jul 01, 2019 at 09:28:06AM +0100, Will Deacon wrote:
> [Note: this was in my spam folder]
> 
> On Fri, Jun 28, 2019 at 06:05:10PM +0000, Saidi, Ali wrote:
> > On 6/7/19, 7:59 AM, " Ali Saidi" <alisaidi@amazon.com> wrote:
> >     On 6/5/19, 7:20 AM, "Will Deacon" <will.deacon@arm.com> wrote:
> >         On Tue, Jun 04, 2019 at 08:30:57PM +0000, Ali Saidi wrote:
> >         > AWS Graviton based systems provide an Arm SMC call in the vendor defined
> >         > hypervisor region to read random numbers from a HW TRNG and return them to the
> >         > guest. 
> >         > 
> >         > We've observed slower guest boot and especially reboot times due to lack of
> >         > entropy and providing access to a TRNG is meant to address this. 
> >         
> >         Curious, but why this over something like virtio-rng?
> >         
> >     This interface allows us to provide the functionality from both EL2
> >     and EL3 and support multiple different types of our instances which we
> >     unfortunately can't do with virt-io.
> >     
> > Any additional comments?
> > Do you know when you'll have a chance to rebase arm64/smccc-cleanup?
> 
> Sorry, Ali, this slipped through the cracks. Marc and I will chat today and
> look at respinning what we had before; it should then hopefully be
> straightforward enough for you to take that as a base for what you want to
> do.

Ok, I hacked on this a bit today and hopefully you can use this as a
starting point:

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

I haven't given it any real testing, so apologies for the bugs.

Will