LinuxLists.cc - [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

[permalink] [raw]

Subject: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).

Signed-off-by: Sudeep Holla <[email protected]>
---
.../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt

diff --git a/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
new file mode 100644
index 000000000000..ee543fb5b397
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
@@ -0,0 +1,47 @@
+Arm Platform Security Architecture(PSA) Firmware Framework(FF) for Armv8-A
+--------------------------------------------------------------------------
+
+This binding is intended to define the interface the firmware framework
+implementing the Non-secure partitions/endpoints(mostly VMs) as described
+in ARM document ARM DEN 0077A ("Arm Platform Security Architecture
+Firmware Framework for Arm v8-A") [0]
+
+In the case of a Non-secure virtual FF-A instance, the hypervisor
+(e.g. Linux KVM) can use this binding to create and launch VM partitions.
+
+The SMCCC conduit available in the VM partition itself is used and hence
+there is no explicit binding to specify the conduit used for PSA FFA
+interface.
+
+Required properties:
+
+- compatible : Should be one of:
+ "arm,psa-ffa"
+
+- One or more child nodes, each describing an PSA FFA partition using the
+ following required properties:
+
+ - compatible: Should be one of:
+ "arm,psa-ffa-partition"
+
+ - uuid : The 128-bit UUID [2] of the service implemented by this partition,
+ represented as a string.
+
+[0] https://developer.arm.com/docs/den0077/latest
+[1] https://tools.ietf.org/html/rfc4122
+
+Example:
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ firmware {
+ psa-ffa {
+ compatible = "arm,psa-ffa";
+
+ partition0: psa_ffa_partition {
+ compatible = "arm,psa-ffa-partition";
+ uuid = "12345678-9abc-def0-1234-56789abcdef0";
+ };
+ };
+ };
--
2.17.1

2020-06-01 09:47:39

[permalink] [raw]

Subject: [RFC PATCH 3/3] firmware: Add example PSA FF-A non-secure VM partition

This is just an example non-secure VM partition to show how to create
the device and use the PSA FF-A interface APIs.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/arm_psa_ffa/Kconfig | 7 +++
drivers/firmware/arm_psa_ffa/Makefile | 1 +
drivers/firmware/arm_psa_ffa/partition.c | 71 ++++++++++++++++++++++++
3 files changed, 79 insertions(+)
create mode 100644 drivers/firmware/arm_psa_ffa/partition.c

diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig
index ba699ec68ec4..34ad61e79234 100644
--- a/drivers/firmware/arm_psa_ffa/Kconfig
+++ b/drivers/firmware/arm_psa_ffa/Kconfig
@@ -13,3 +13,10 @@ config ARM_PSA_FFA_TRANSPORT

This driver provides interface for all the client drivers making
use of the features offered by ARM PSA-FF-A.
+
+config ARM_PSA_FFA_PARTITION
+ tristate "Arm PSA FF-A compliant partition"
+ depends on ARM_PSA_FFA_TRANSPORT
+ help
+ This driver provides example for ARM PSA-FF-A client driver
+ making use of the interfaces offered by ARM PSA-FF-A driver.
diff --git a/drivers/firmware/arm_psa_ffa/Makefile b/drivers/firmware/arm_psa_ffa/Makefile
index ac0455ff71a4..8eb03898baf7 100644
--- a/drivers/firmware/arm_psa_ffa/Makefile
+++ b/drivers/firmware/arm_psa_ffa/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_ARM_PSA_FFA_TRANSPORT) += driver.o
+obj-$(CONFIG_ARM_PSA_FFA_PARTITION) += partition.o
diff --git a/drivers/firmware/arm_psa_ffa/partition.c b/drivers/firmware/arm_psa_ffa/partition.c
new file mode 100644
index 000000000000..8549f8d61454
--- /dev/null
+++ b/drivers/firmware/arm_psa_ffa/partition.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Arm PSA FFA example partition driver
+ *
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+#include <linux/arm_psa_ffa.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/uuid.h>
+
+static int psa_ffa_partition_probe(struct platform_device *pdev)
+{
+ u16 vm_id;
+ uuid_t uuid;
+ const char *uuid_str;
+ u32 uuid0_4[4];
+ struct device *dev = &pdev->dev;
+ const struct device_node *np = dev->of_node;
+ struct arm_psa_ffa_handle *handle;
+ struct psa_ffa_partition_info **buffer;
+
+ handle = arm_psa_ffa_handle_get(dev);
+ if (!handle)
+ return -ENODEV;
+
+ if (of_property_read_string(np, "uuid", &uuid_str)) {
+ dev_err(dev, "failed to parse \"uuid\" property in '%pOF'\n", np);
+ return -ENODEV;
+ }
+
+ if (uuid_parse(uuid_str, &uuid)) {
+ dev_err(dev, "invalid \"uuid\" property (%s)\n", uuid_str);
+ return -ENODEV;
+ }
+
+ export_uuid((u8 *)uuid0_4, &uuid);
+
+ vm_id = handle->id_get();
+
+ handle->partition_info_get(uuid0_4[0], uuid0_4[1], uuid0_4[2],
+ uuid0_4[3], buffer);
+
+ return 0;
+}
+
+static const struct of_device_id psa_ffa_partition_of_match[] = {
+ {.compatible = "arm,psa-ffa-partition"},
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, psa_ffa_partition_of_match);
+
+static struct platform_driver psa_ffa_partition_driver = {
+ .driver = {
+ .name = "psa-ffa-partition",
+ .of_match_table = psa_ffa_partition_of_match,
+ },
+ .probe = psa_ffa_partition_probe,
+};
+
+module_platform_driver(psa_ffa_partition_driver);
+
+MODULE_ALIAS("platform: arm-psa-ffa");
+MODULE_AUTHOR("Sudeep Holla <[email protected]>");
+MODULE_DESCRIPTION("Arm PSA FF-A example partition driver");
+MODULE_LICENSE("GPL v2");
--
2.17.1

2020-06-01 09:48:21

[permalink] [raw]

Subject: [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for VM partitions

Initial support for PSA FF-A interface providing APIs for non-secure VM
partitions.

Signed-off-by: Sudeep Holla <[email protected]>
---
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/arm_psa_ffa/Kconfig | 15 ++
drivers/firmware/arm_psa_ffa/Makefile | 2 +
drivers/firmware/arm_psa_ffa/driver.c | 250 ++++++++++++++++++++++++++
include/linux/arm_psa_ffa.h | 42 +++++
6 files changed, 311 insertions(+)
create mode 100644 drivers/firmware/arm_psa_ffa/Kconfig
create mode 100644 drivers/firmware/arm_psa_ffa/Makefile
create mode 100644 drivers/firmware/arm_psa_ffa/driver.c
create mode 100644 include/linux/arm_psa_ffa.h

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 4843e94713a4..1ee421974cba 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -295,6 +295,7 @@ config TURRIS_MOX_RWTM
other manufacturing data and also utilize the Entropy Bit Generator
for hardware random number generation.

+source "drivers/firmware/arm_psa_ffa/Kconfig"
source "drivers/firmware/broadcom/Kconfig"
source "drivers/firmware/google/Kconfig"
source "drivers/firmware/efi/Kconfig"
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 99510be9f5ed..1c0b5f130d7d 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o

+obj-y += arm_psa_ffa/
obj-$(CONFIG_ARM_SCMI_PROTOCOL) += arm_scmi/
obj-y += broadcom/
obj-y += meson/
diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig
new file mode 100644
index 000000000000..ba699ec68ec4
--- /dev/null
+++ b/drivers/firmware/arm_psa_ffa/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config ARM_PSA_FFA_TRANSPORT
+ tristate "Arm Platform Security Architecture Firmware Framework for Armv8-A"
+ depends on ARM64 && HAVE_ARM_SMCCC_DISCOVERY
+ help
+ This Firmware Framework(FF) of the Platform Security Architecture
+ (PSA) for Arm A-profile processors describes interfaces that
+ standardize communication between the various software images which
+ includes communication between images in the Secure world and
+ Normal world. It also leverages the virtualization extension to
+ isolate software images provided by an ecosystem of vendors from
+ each other.
+
+ This driver provides interface for all the client drivers making
+ use of the features offered by ARM PSA-FF-A.
diff --git a/drivers/firmware/arm_psa_ffa/Makefile b/drivers/firmware/arm_psa_ffa/Makefile
new file mode 100644
index 000000000000..ac0455ff71a4
--- /dev/null
+++ b/drivers/firmware/arm_psa_ffa/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ARM_PSA_FFA_TRANSPORT) += driver.o
diff --git a/drivers/firmware/arm_psa_ffa/driver.c b/drivers/firmware/arm_psa_ffa/driver.c
new file mode 100644
index 000000000000..700bd5850746
--- /dev/null
+++ b/drivers/firmware/arm_psa_ffa/driver.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Arm Platform Security Architecture(PSA) Firmware Framework for ARMv8-A(FFA)
+ * interface driver
+ *
+ * The Arm PSA FFA specification[1] describes a software architecture to
+ * leverages the virtualization extension to isolate software images
+ * provided by an ecosystem of vendors from each other and describes
+ * interfaces that standardize communication between the various software
+ * images including communication between images in the Secure world and
+ * Normal world. Any Hypervisor could use the PSA FFA interfaces to enable
+ * communication between VMs it manages.
+ *
+ * The Hypervisor a.k.a Partition managers in FFA terminology can assign
+ * system resources(Memory regions, Devices, CPU cycles) to the partitions
+ * and manage isolation amongst them.
+ *
+ * [1] https://developer.arm.com/docs/den0077/latest
+ *
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+#define pr_fmt(fmt) "ARM PSA FF-A: " fmt
+
+#include <linux/arm_psa_ffa.h>
+#include <linux/arm-smccc.h>
+#include <linux/bitfield.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/types.h>
+
+#define PSA_FFA_SMC(calling_convention, func_num) \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, (calling_convention), \
+ ARM_SMCCC_OWNER_STANDARD, (func_num))
+
+#define PSA_FFA_SMC_32(func_num) PSA_FFA_SMC(ARM_SMCCC_SMC_32, (func_num))
+#define PSA_FFA_SMC_64(func_num) PSA_FFA_SMC(ARM_SMCCC_SMC_64, (func_num))
+
+#define PSA_FFA_ERROR PSA_FFA_SMC_32(0x60)
+#define PSA_FFA_SUCCESS PSA_FFA_SMC_32(0x61)
+#define PSA_FFA_INTERRUPT PSA_FFA_SMC_32(0x62)
+#define PSA_FFA_VERSION PSA_FFA_SMC_32(0x63)
+#define PSA_FFA_FEATURES PSA_FFA_SMC_32(0x64)
+#define PSA_FFA_PARTITION_INFO_GET PSA_FFA_SMC_32(0x68)
+#define PSA_FFA_ID_GET PSA_FFA_SMC_32(0x69)
+
+/* PSA_FFA error codes. */
+#define PSA_FFA_RET_SUCCESS (0)
+#define PSA_FFA_RET_NOT_SUPPORTED (-1)
+#define PSA_FFA_RET_INVALID_PARAMETERS (-2)
+#define PSA_FFA_RET_NO_MEMORY (-3)
+#define PSA_FFA_RET_BUSY (-4)
+#define PSA_FFA_RET_INTERRUPTED (-5)
+#define PSA_FFA_RET_DENIED (-6)
+#define PSA_FFA_RET_RETRY (-7)
+#define PSA_FFA_RET_ABORTED (-8)
+
+#define MAJOR_VERSION_MASK GENMASK(30, 16)
+#define MINOR_VERSION_MASK GENMASK(15, 0)
+#define MAJOR_VERSION(x) (u16)(FIELD_GET(MAJOR_VERSION_MASK, (x)))
+#define MINOR_VERSION(x) (u16)(FIELD_GET(MINOR_VERSION_MASK, (x)))
+#define PACK_VERSION_INFO(major, minor) \
+ (FIELD_PREP(MAJOR_VERSION_MASK, (major)) | \
+ FIELD_PREP(MINOR_VERSION_MASK, (minor)))
+#define PSA_FFA_VERSION_1_0 PACK_VERSION_INFO(1, 0)
+#define PSA_FFA_MIN_VERSION PSA_FFA_VERSION_1_0
+#define PSA_FFA_DRIVER_VERSION PSA_FFA_VERSION_1_0
+
+#define SENDER_ID_MASK GENMASK(31, 16)
+#define RECEIVER_ID_MASK GENMASK(15, 0)
+#define SENDER_ID(x) (u16)(FIELD_GET(SENDER_ID_MASK, (x)))
+#define RECEIVER_ID(x) (u16)(FIELD_GET(RECEIVER_ID_MASK, (x)))
+#define PACK_TARGET_INFO(s, r) \
+ (FIELD_PREP(SENDER_ID_MASK, (s)) | FIELD_PREP(RECEIVER_ID_MASK, (r)))
+
+typedef struct arm_smccc_res
+(arm_psa_ffa_fn)(unsigned long, unsigned long, unsigned long, unsigned long,
+ unsigned long, unsigned long, unsigned long, unsigned long);
+static arm_psa_ffa_fn *invoke_arm_psa_ffa_fn;
+
+static struct device *psa_ffa_dev;
+
+static const int psa_ffa_linux_errmap[] = {
+ /* better than switch case as long as return value is continuous */
+ 0, /* PSA_FFA_RET_SUCCESS */
+ -EOPNOTSUPP, /* PSA_FFA_RET_NOT_SUPPORTED */
+ -EINVAL, /* PSA_FFA_RET_INVALID_PARAMETERS */
+ -ENOMEM, /* PSA_FFA_RET_NO_MEMORY */
+ -EBUSY, /* PSA_FFA_RET_BUSY */
+ -EINTR, /* PSA_FFA_RET_INTERRUPTED */
+ -EACCES, /* PSA_FFA_RET_DENIED */
+ -EAGAIN, /* PSA_FFA_RET_RETRY */
+ -ECANCELED, /* PSA_FFA_RET_ABORTED */
+};
+
+static inline int psa_ffa_to_linux_errno(int errno)
+{
+ if (errno < PSA_FFA_RET_SUCCESS && errno >= PSA_FFA_RET_ABORTED)
+ return psa_ffa_linux_errmap[-errno];
+ return -EINVAL;
+}
+
+struct arm_smccc_res
+__arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0,
+ unsigned long arg1, unsigned long arg2,
+ unsigned long arg3, unsigned long arg4,
+ unsigned long arg5, unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6,
+ &res);
+
+ return res;
+}
+
+struct arm_smccc_res
+__arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0,
+ unsigned long arg1, unsigned long arg2,
+ unsigned long arg3, unsigned long arg4,
+ unsigned long arg5, unsigned long arg6)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6,
+ &res);
+
+ return res;
+}
+
+static u16 psa_ffa_id_get(void)
+{
+ struct arm_smccc_res id;
+
+ id = invoke_arm_psa_ffa_fn(PSA_FFA_ID_GET, 0, 0, 0, 0, 0, 0, 0);
+
+ if (id.a0 == PSA_FFA_ERROR)
+ return psa_ffa_to_linux_errno((int)id.a2);
+ else
+ return id.a2 & 0xffff;
+}
+
+static int psa_ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
+ struct psa_ffa_partition_info **buffer)
+{
+ struct arm_smccc_res partition_info;
+
+ partition_info = invoke_arm_psa_ffa_fn(PSA_FFA_PARTITION_INFO_GET,
+ uuid0, uuid1, uuid2, uuid3,
+ 0, 0, 0);
+
+ if (partition_info.a0 == PSA_FFA_ERROR)
+ return psa_ffa_to_linux_errno((int)partition_info.a2);
+
+ /* TODO: read data from RX buffers */
+ return partition_info.a2;
+}
+
+static struct arm_psa_ffa_handle drv_handle = {
+ .id_get = psa_ffa_id_get,
+ .partition_info_get = psa_ffa_partition_info_get,
+};
+
+struct arm_psa_ffa_handle *arm_psa_ffa_handle_get(struct device *dev)
+{
+ struct arm_psa_ffa_handle *handle = NULL;
+
+ if (dev->parent == psa_ffa_dev)
+ handle = &drv_handle;
+
+ return handle;
+}
+
+EXPORT_SYMBOL_GPL(arm_psa_ffa_handle_get);
+
+static int psa_ffa_version_check(void)
+{
+ struct arm_smccc_res version;
+
+ version = invoke_arm_psa_ffa_fn(PSA_FFA_VERSION, PSA_FFA_DRIVER_VERSION,
+ 0, 0, 0, 0, 0, 0);
+
+ if (version.a0 == PSA_FFA_RET_NOT_SUPPORTED) {
+ pr_info("PSA_FFA_VERSION returned not supported\n");
+ return -ENOTSUPP;
+ }
+
+ if (version.a0 < PSA_FFA_MIN_VERSION ||
+ version.a0 > PSA_FFA_DRIVER_VERSION) {
+ pr_err("Incompatible version %d.%d found\n",
+ MAJOR_VERSION(version.a0), MINOR_VERSION(version.a0));
+ return -EINVAL;
+ }
+
+ pr_info("Found version %d.%d found\n", MAJOR_VERSION(version.a0),
+ MINOR_VERSION(version.a0));
+ return 0;
+}
+
+static int psa_ffa_probe(struct platform_device *pdev)
+{
+ int ret;
+ enum arm_smccc_conduit conduit;
+
+ if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2)
+ return 0;
+
+ conduit = arm_smccc_1_1_get_conduit();
+ if (conduit == SMCCC_CONDUIT_NONE) {
+ pr_err("%s: invalid SMCCC conduit\n", __func__);
+ return -EOPNOTSUPP;
+ }
+
+ if (conduit == SMCCC_CONDUIT_SMC)
+ invoke_arm_psa_ffa_fn = __arm_psa_ffa_fn_smc;
+ else
+ invoke_arm_psa_ffa_fn = __arm_psa_ffa_fn_hvc;
+
+ ret = psa_ffa_version_check();
+ if (ret)
+ return ret;
+
+ psa_ffa_dev = &pdev->dev;
+
+ return devm_of_platform_populate(psa_ffa_dev);
+}
+
+static const struct of_device_id psa_ffa_of_match[] = {
+ {.compatible = "arm,psa-ffa"},
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, psa_ffa_of_match);
+
+static struct platform_driver psa_ffa_driver = {
+ .driver = {
+ .name = "arm-psa-ffa",
+ .of_match_table = psa_ffa_of_match,
+ },
+ .probe = psa_ffa_probe,
+};
+
+module_platform_driver(psa_ffa_driver);
+
+MODULE_ALIAS("platform: arm-psa-ffa");
+MODULE_AUTHOR("Sudeep Holla <[email protected]>");
+MODULE_DESCRIPTION("Arm PSA FF-A interface driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/arm_psa_ffa.h b/include/linux/arm_psa_ffa.h
new file mode 100644
index 000000000000..03a4ff559fa3
--- /dev/null
+++ b/include/linux/arm_psa_ffa.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019, 2020 Arm Ltd.
+ */
+
+#ifndef __LINUX_ARM_PSA_FFA_H
+#define __LINUX_ARM_PSA_FFA_H
+
+#include <linux/device.h>
+#include <linux/types.h>
+
+struct psa_ffa_partition_info {
+ /* The ID of the VM the information is about */
+ uint16_t id;
+ /* The number of execution contexts implemented by the partition */
+ uint16_t execution_context;
+ /* The Partition's properties, e.g. supported messaging methods */
+ uint32_t partition_properties;
+};
+
+
+/**
+ * struct psa_ffa_ops - represents the various PSA_FFA protocol operations
+ * available for an endpoint.
+ */
+struct arm_psa_ffa_handle {
+ u16 (*id_get)(void);
+ int (*partition_info_get)(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
+ struct psa_ffa_partition_info**);
+};
+
+#if IS_REACHABLE(CONFIG_ARM_PSA_FFA_TRANSPORT)
+struct arm_psa_ffa_handle *arm_psa_ffa_handle_get(struct device *dev);
+#else
+static inline
+struct arm_psa_ffa_handle * arm_psa_ffa_handle_get(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
+#endif /*__LINUX_ARM_PSA_FFA_H*/
--
2.17.1

2020-06-04 13:40:40

[permalink] [raw]

Subject: Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

Hi Sudeep, [+Fuad, Andrew and Ard]

(To other interested readers: if you haven't seen it, the FF-A spec is here:
https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf
since this discussion makes no sense without that, and a tiny bit of sense
with it. It used to be called "SPCI" but it was recently renamed.)

On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
> Sorry for posting in the middle of merge window and I must have done
> this last week itself. This is not the driver I had thought about posting
> last week. After I started cleaning up and looking at Will's KVM prototype[1]
> for PSA FF-A (previously known as SPCI),

Yes, I need to do the Big Rename at some point. Joy.

> I got more doubts on alignment and dropped huge chunk of interface APIs in
> the driver in order to keep it simple, and get aligned more with that
> prototype and avoid scanning lots of code unnecessary.

You also dropped most of the code, so this doesn't really do anything in
its current form ;)

> Here are few things to clarify:
>
> 1. DT bindings
> ---------------
> I was initially against adding bindings for Tx/Rx buffers for
> partitions. As per the spec, an endpoint could allocate the
> buffer pair and use the FFA_RXTX_MAP interface to map it with the
> Hypervisor(KVM here). However looking at the prototype and also
> I remember you mentioning that it is not possible to manage buffers
> in that way. Please confirm if you plan to add the buffer details
> fetcthing them through ioctls in KVM and adding them to VM DT nodes
> in KVM userspace. I will update the bindings accordingly.

I think it's useful to have a mode of operation where the hypervisor
allocates the RX/TX buffers and advertises them in the DT. However, we
can always add this later, so there's no need to have it in the binding
from the start. Best start as simple as possible, I reckon.

Setting the static RX/TX buffer allocation aside, why is a DT node needed
at all for the case where Linux is running purely as an FF-A client? I
thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
without a binding at all for the client case.

> 2. Driver
> ---------
> a. Support for multiple partitions in a VM
> ------------------------------------------
> I am not sure if there is need for supporting multiple partitions
> within a VM. It should be possible to do so as I expect to create
> device for each partition entry under arm-psa-ffa devicetree node.
> However, I don't want to assume something that will never be a
> usecase. However I don't think this will change must of the
> abstraction as we need to keep the interface API implementation
> separate to support different partitions on various platforms.

I think Ard has a case for something like this, where a VM actually consists
of multiple partitions so that S-EL0 services can be provided from NS-EL0.
However, he probably wants that for a dynamically created VM, so we'd
need a way to instantiate an FFA namespace for the VM. Maybe that can be
done entirely in userspace by the VMM...

> b. SMCCC interface
> ------------------
> This is something I messed up completely while trying to add
> support for SMCCC v1.2. It now supports x0-x17 as parameter
> registers(input) and return registers(output). I started simple
> with x0-x7 as both input and output as PSA FF-A needs that at
> most. But extending to x0-x17 then became with messy in my
> implementation. That's the reason I dropped it completely
> here and thought of checking it first.
>
> Do we need to extend the optimisations that were done to handle
> ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
> as both input and ouput. Hyper-V guys need full x0-x17 support.
>
> I need some guidance as what is the approach preferred ?

I think we can start off with x0-x7 and extend if later if we need to.

> 3. Partitions
> -------------
> I am not sure if we have a full define partition that we plan to
> push upstream. Without one, we can have a sample/example partition
> to test all the interface APIs, but is that fine with respect to
> what we want upstream ? Any other thoughts that helps to test the
> driver ?

I think that's the best you can do for now. We can probably help with
testing as our stuff gets off the ground.

> Sorry for long email and too many questions, but I thought it is easier
> this way to begin with than throwing huge code implementing loads of APIs
> with no users(expect example partition) especially that I am posting this
> during merge window.

No problem. Maybe it would help if I described roughly what we were thinking
of doing for KVM (this is open for discussion, of course):

1. Describe KVM-managed partitions in the DT, along the lines of [1]
2. Expose each partition as a file to userspace. E.g.:

/dev/spci/:

self
e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
49f65057-d002-4ae2-b4ee-d31c7940a13d

Here, self would be a symlink to the host uuid. The host uuid file
would implement FFA_MEM operations using an ioctl(), so you could,
for example, share a user buffer with multiple partitions by issuing
a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
as arguments. Messaging would be implemented as ioctl()s on the
partition uuid files themselves.

3. We'll need some (all?) of these patches to unmap memory from the host
when necessary:

https://lwn.net/Articles/821215/

(for nVHE, we'll have a stage-2 for the host so we can unmap there as
well)

For communicating with partitions that are not managed by KVM (e.g. trusted
applications), it's not clear to me how much of that will be handled in
kernel or user. I think it would still be worth exposing the partitions as
files, but perhaps having them root only or just returning -EPERM for the
ioctl() if a kernel driver has claimed the partition as its own? Ideally,
FF-A would allow us to transition some of the Trusted OS interfacing code
out to userspace, but I don't know how realistic that is.

Anyway, to enable this, I think we need a clear separation in the kernel
between the FF-A code and the users: KVM will want to expose things as
above, but if drivers need to use this stuff as well then they can plug in
as additional users and we don't have to worry about tripping over the
RX/TX buffers etc.

What do you think, and do you reckon you can spin a cut-down driver that
implements the common part of the logic (since I know you've written much
of this code already)?

Cheers,

Will

[1] https://android-kvm.googlesource.com/linux/+/8632a5723ef106017c4ab57e95d9ce7630d35522%5E%21/#F0

2020-06-09 19:44:17

[permalink] [raw]

Subject: Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

(Sorry for the delay, got distracted with some other bug fix.)

On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote:
> Hi Sudeep, [+Fuad, Andrew and Ard]
>
> (To other interested readers: if you haven't seen it, the FF-A spec is here:
> https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf
> since this discussion makes no sense without that, and a tiny bit of sense
> with it. It used to be called "SPCI" but it was recently renamed.)
>

Thanks for adding all interested parties.

> On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
> > Sorry for posting in the middle of merge window and I must have done
> > this last week itself. This is not the driver I had thought about posting
> > last week. After I started cleaning up and looking at Will's KVM prototype[1]
> > for PSA FF-A (previously known as SPCI),
>
> Yes, I need to do the Big Rename at some point. Joy.
>

????

> > I got more doubts on alignment and dropped huge chunk of interface APIs in
> > the driver in order to keep it simple, and get aligned more with that
> > prototype and avoid scanning lots of code unnecessary.
>
> You also dropped most of the code, so this doesn't really do anything in
> its current form ;)
>

Yes, it was intentional ????

> > Here are few things to clarify:
> >
> > 1. DT bindings
> > ---------------
> > I was initially against adding bindings for Tx/Rx buffers for
> > partitions. As per the spec, an endpoint could allocate the
> > buffer pair and use the FFA_RXTX_MAP interface to map it with the
> > Hypervisor(KVM here). However looking at the prototype and also
> > I remember you mentioning that it is not possible to manage buffers
> > in that way. Please confirm if you plan to add the buffer details
> > fetcthing them through ioctls in KVM and adding them to VM DT nodes
> > in KVM userspace. I will update the bindings accordingly.
>
> I think it's useful to have a mode of operation where the hypervisor
> allocates the RX/TX buffers and advertises them in the DT. However, we
> can always add this later, so there's no need to have it in the binding
> from the start. Best start as simple as possible, I reckon.
>

OK

> Setting the static RX/TX buffer allocation aside, why is a DT node needed
> at all for the case where Linux is running purely as an FF-A client? I
> thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
> FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
> without a binding at all for the client case.
>

Agreed, I added for RxTx buffers and initially to build the parent/child
hierarchy for all users of the driver. Initially I was assuming only
in-kernel users and now I agree we should avoid any in kernel users if
possible.

One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
information to the caller. So we need to have established buffers before
that and one of the reason you don't find that in this RFC. I dropped that
too which I wanted initially.

> > 2. Driver
> > ---------
> > a. Support for multiple partitions in a VM
> > ------------------------------------------
> > I am not sure if there is need for supporting multiple partitions
> > within a VM. It should be possible to do so as I expect to create
> > device for each partition entry under arm-psa-ffa devicetree node.
> > However, I don't want to assume something that will never be a
> > usecase. However I don't think this will change must of the
> > abstraction as we need to keep the interface API implementation
> > separate to support different partitions on various platforms.
>
> I think Ard has a case for something like this, where a VM actually consists
> of multiple partitions so that S-EL0 services can be provided from NS-EL0.
> However, he probably wants that for a dynamically created VM, so we'd
> need a way to instantiate an FFA namespace for the VM. Maybe that can be
> done entirely in userspace by the VMM...
>

Interesting...

> > b. SMCCC interface
> > ------------------
> > This is something I messed up completely while trying to add
> > support for SMCCC v1.2. It now supports x0-x17 as parameter
> > registers(input) and return registers(output). I started simple
> > with x0-x7 as both input and output as PSA FF-A needs that at
> > most. But extending to x0-x17 then became with messy in my
> > implementation. That's the reason I dropped it completely
> > here and thought of checking it first.
> >
> > Do we need to extend the optimisations that were done to handle
> > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
> > as both input and ouput. Hyper-V guys need full x0-x17 support.
> >
> > I need some guidance as what is the approach preferred ?
>
> I think we can start off with x0-x7 and extend if later if we need to.
>

Sure

> > 3. Partitions
> > -------------
> > I am not sure if we have a full define partition that we plan to
> > push upstream. Without one, we can have a sample/example partition
> > to test all the interface APIs, but is that fine with respect to
> > what we want upstream ? Any other thoughts that helps to test the
> > driver ?
>
> I think that's the best you can do for now. We can probably help with
> testing as our stuff gets off the ground.
>

OK

> > Sorry for long email and too many questions, but I thought it is easier
> > this way to begin with than throwing huge code implementing loads of APIs
> > with no users(expect example partition) especially that I am posting this
> > during merge window.
>
> No problem. Maybe it would help if I described roughly what we were thinking
> of doing for KVM (this is open for discussion, of course):
>
> 1. Describe KVM-managed partitions in the DT, along the lines of [1]
> 2. Expose each partition as a file to userspace. E.g.:
>
> /dev/spci/:
>
> self
> e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
> 49f65057-d002-4ae2-b4ee-d31c7940a13d
>
> Here, self would be a symlink to the host uuid. The host uuid file
> would implement FFA_MEM operations using an ioctl(), so you could,
> for example, share a user buffer with multiple partitions by issuing
> a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
> as arguments. Messaging would be implemented as ioctl()s on the
> partition uuid files themselves.
>

OK, IIUC that covers mostly KVM implementation. We still need a way to
share the RxTx buffer info to the partitions and DT/ACPI(?) is one
possible way. Based on you comment about not needing DT node, do you have
any other way to communicate the buffer info to the partitions ?

> 3. We'll need some (all?) of these patches to unmap memory from the host
> when necessary:
>
> https://lwn.net/Articles/821215/
>
> (for nVHE, we'll have a stage-2 for the host so we can unmap there as
> well)
>

Sounds more fun.

> For communicating with partitions that are not managed by KVM (e.g. trusted
> applications), it's not clear to me how much of that will be handled in
> kernel or user. I think it would still be worth exposing the partitions as
> files, but perhaps having them root only or just returning -EPERM for the
> ioctl() if a kernel driver has claimed the partition as its own? Ideally,
> FF-A would allow us to transition some of the Trusted OS interfacing code
> out to userspace, but I don't know how realistic that is.
>

Ah good, so we can still manage in-kernel users this way but we need to
provide interface to such a driver which I agree that we need to avoid
if possible.

> Anyway, to enable this, I think we need a clear separation in the kernel
> between the FF-A code and the users:
Agreed.

> KVM will want to expose things as above, but if drivers need to use this
> stuff as well then they can plug in as additional users and we don't have to
> worry about tripping over the RX/TX buffers etc.
>

I am confused a bit. When you refer drivers above, are you referring to
drivers in host kernel(hypervisor) or in the partitions. I fail to
imagine need for the former.

> What do you think, and do you reckon you can spin a cut-down driver that
> implements the common part of the logic (since I know you've written much
> of this code already)?
>

I am not sure if I am aligned with your thoughts on the buffer sharing
yet.

--
Regards,
Sudeep

2020-06-09 22:40:28

by Rob Herring (Arm)

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> at virtual interface(VMs).
>
> Signed-off-by: Sudeep Holla <[email protected]>
> ---
> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt

I'm hoping this goes away if the firmware is discoverable, but if not DT
bindings are DT schema now.

Rob

2020-06-10 07:48:33

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> > at virtual interface(VMs).
> >
> > Signed-off-by: Sudeep Holla <[email protected]>
> > ---
> > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> > 1 file changed, 47 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
>
> I'm hoping this goes away if the firmware is discoverable, but if not DT
> bindings are DT schema now.

We'll need the binding for the kvm host side, because there are plenty
of partition properties that are not discoverable (e.g. number of vCPUs).

I'll have a go a yamlifying what I have...

Will

2020-06-10 08:15:14

[permalink] [raw]

Subject: Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

Hi Will,

On Wed, Jun 10, 2020 at 08:57:12AM +0100, Will Deacon wrote:
> Hi Sudeep,
>
> On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote:

[...]

> >
> > Agreed, I added for RxTx buffers and initially to build the parent/child
> > hierarchy for all users of the driver. Initially I was assuming only
> > in-kernel users and now I agree we should avoid any in kernel users if
> > possible.
> >
> > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
> > information to the caller. So we need to have established buffers before
> > that and one of the reason you don't find that in this RFC. I dropped that
> > too which I wanted initially.
>
> Ok, sounds like we should at least get to a position where we can enumerate
> things, though.
>

Yes.

[...]

> >
> > OK, IIUC that covers mostly KVM implementation. We still need a way to
> > share the RxTx buffer info to the partitions and DT/ACPI(?) is one
> > possible way. Based on you comment about not needing DT node, do you have
> > any other way to communicate the buffer info to the partitions ?
>
> This is only a concern if KVM chooses to provide the Rx/Tx buffer pair
> though, right? If we punt that down the road for the moment, then we can
> just rely on FFA_RXTX_MAP for now.
>

Ah OK, I was under the assumption that we didn't want to use FFA_RXTX_{,UN}MAP

[...]

> >
> > I am confused a bit. When you refer drivers above, are you referring to
> > drivers in host kernel(hypervisor) or in the partitions. I fail to
> > imagine need for the former.
>
> I'm referring to in-kernel users in the host kernel. For KVM-managed guests,
> we may not need these, although signalling things like system shutdown might
> be better off done without relying on userspace. But my point is really that
> separating the buffer management from the users means we can serialise
> consumers, whether they are in-kernel or out in userspace.
>

Understood.

> > > What do you think, and do you reckon you can spin a cut-down driver that
> > > implements the common part of the logic (since I know you've written much
> > > of this code already)?
> > >
> >
> > I am not sure if I am aligned with your thoughts on the buffer sharing
> > yet.
>
> Ok, please let me know if you have any more questions.
>

None ATM. As I mentioned I had ruled out RXTX_{,UN}MAP which was my
misunderstanding.

--
Regards,
Sudeep

2020-06-10 14:02:41

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> > at virtual interface(VMs).
> >
> > Signed-off-by: Sudeep Holla <[email protected]>
> > ---
> > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> > 1 file changed, 47 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
>
> I'm hoping this goes away if the firmware is discoverable, but if not DT
> bindings are DT schema now.
>

Yes, consider it gone. I introduced it to couple of reasons both of which
are now irrelevant. We may revisit this if we need it for Rx/Tx buffer
information. The KVM host may need the binding, this was for the guests/
partitions as Will has already mentioned.

--
Regards,
Sudeep

2020-06-10 14:27:49

[permalink] [raw]

Subject: Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

Hi Sudeep,

On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote:
> On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote:
> > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
> > > Sorry for posting in the middle of merge window and I must have done
> > > this last week itself. This is not the driver I had thought about posting
> > > last week. After I started cleaning up and looking at Will's KVM prototype[1]
> > > for PSA FF-A (previously known as SPCI),
> >
> > Yes, I need to do the Big Rename at some point. Joy.
> >
>
> ????

Renamed version here:

https://android-kvm.googlesource.com/linux/+/refs/heads/willdeacon/psa-ffa

although I haven't psyched myself up to write yaml yet.

> > Setting the static RX/TX buffer allocation aside, why is a DT node needed
> > at all for the case where Linux is running purely as an FF-A client? I
> > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
> > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
> > without a binding at all for the client case.
> >
>
> Agreed, I added for RxTx buffers and initially to build the parent/child
> hierarchy for all users of the driver. Initially I was assuming only
> in-kernel users and now I agree we should avoid any in kernel users if
> possible.
>
> One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
> information to the caller. So we need to have established buffers before
> that and one of the reason you don't find that in this RFC. I dropped that
> too which I wanted initially.

Ok, sounds like we should at least get to a position where we can enumerate
things, though.

> > > Sorry for long email and too many questions, but I thought it is easier
> > > this way to begin with than throwing huge code implementing loads of APIs
> > > with no users(expect example partition) especially that I am posting this
> > > during merge window.
> >
> > No problem. Maybe it would help if I described roughly what we were thinking
> > of doing for KVM (this is open for discussion, of course):
> >
> > 1. Describe KVM-managed partitions in the DT, along the lines of [1]
> > 2. Expose each partition as a file to userspace. E.g.:
> >
> > /dev/spci/:
> >
> > self
> > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
> > 49f65057-d002-4ae2-b4ee-d31c7940a13d
> >
> > Here, self would be a symlink to the host uuid. The host uuid file
> > would implement FFA_MEM operations using an ioctl(), so you could,
> > for example, share a user buffer with multiple partitions by issuing
> > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
> > as arguments. Messaging would be implemented as ioctl()s on the
> > partition uuid files themselves.
> >
>
> OK, IIUC that covers mostly KVM implementation. We still need a way to
> share the RxTx buffer info to the partitions and DT/ACPI(?) is one
> possible way. Based on you comment about not needing DT node, do you have
> any other way to communicate the buffer info to the partitions ?

This is only a concern if KVM chooses to provide the Rx/Tx buffer pair
though, right? If we punt that down the road for the moment, then we can
just rely on FFA_RXTX_MAP for now.

> > For communicating with partitions that are not managed by KVM (e.g. trusted
> > applications), it's not clear to me how much of that will be handled in
> > kernel or user. I think it would still be worth exposing the partitions as
> > files, but perhaps having them root only or just returning -EPERM for the
> > ioctl() if a kernel driver has claimed the partition as its own? Ideally,
> > FF-A would allow us to transition some of the Trusted OS interfacing code
> > out to userspace, but I don't know how realistic that is.
> >
>
> Ah good, so we can still manage in-kernel users this way but we need to
> provide interface to such a driver which I agree that we need to avoid
> if possible.
>
> > Anyway, to enable this, I think we need a clear separation in the kernel
> > between the FF-A code and the users:
> Agreed.
>
> > KVM will want to expose things as above, but if drivers need to use this
> > stuff as well then they can plug in as additional users and we don't have to
> > worry about tripping over the RX/TX buffers etc.
> >
>
> I am confused a bit. When you refer drivers above, are you referring to
> drivers in host kernel(hypervisor) or in the partitions. I fail to
> imagine need for the former.

I'm referring to in-kernel users in the host kernel. For KVM-managed guests,
we may not need these, although signalling things like system shutdown might
be better off done without relying on userspace. But my point is really that
separating the buffer management from the users means we can serialise
consumers, whether they are in-kernel or out in userspace.

> > What do you think, and do you reckon you can spin a cut-down driver that
> > implements the common part of the logic (since I know you've written much
> > of this code already)?
> >
>
> I am not sure if I am aligned with your thoughts on the buffer sharing
> yet.

Ok, please let me know if you have any more questions.

Will

2020-06-10 16:39:41

by Rob Herring (Arm)

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Wed, Jun 10, 2020 at 1:43 AM Will Deacon <[email protected]> wrote:
>
> On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
> > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> > > at virtual interface(VMs).
> > >
> > > Signed-off-by: Sudeep Holla <[email protected]>
> > > ---
> > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> > > 1 file changed, 47 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
> >
> > I'm hoping this goes away if the firmware is discoverable, but if not DT
> > bindings are DT schema now.
>
> We'll need the binding for the kvm host side, because there are plenty
> of partition properties that are not discoverable (e.g. number of vCPUs).

BTW, there's already a partitioning binding for Power in ePAPR. I've
not paid much attention to it, but maybe it could be useful here.

Rob

2020-06-11 15:52:18

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

Hi Will,

> On 10 Jun 2020, at 08:43, Will Deacon <[email protected]> wrote:
>
> On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
>> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
>>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
>>> at virtual interface(VMs).
>>>
>>> Signed-off-by: Sudeep Holla <[email protected]>
>>> ---
>>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
>>> 1 file changed, 47 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
>>
>> I'm hoping this goes away if the firmware is discoverable, but if not DT
>> bindings are DT schema now.
>
> We'll need the binding for the kvm host side, because there are plenty
> of partition properties that are not discoverable (e.g. number of vCPUs).

Just trying to understand the req. a bit better…

The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine the count of partitions and their vCPUs.

Is this about a guest being able to find out how many vCPUs it has?

Cheers,
Achin

>
> I'll have a go a yamlifying what I have...
>
> Will
>

2020-06-11 19:14:26

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote:
> > On 10 Jun 2020, at 08:43, Will Deacon <[email protected]> wrote:
> > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
> >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> >>> at virtual interface(VMs).
> >>>
> >>> Signed-off-by: Sudeep Holla <[email protected]>
> >>> ---
> >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> >>> 1 file changed, 47 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
> >>
> >> I'm hoping this goes away if the firmware is discoverable, but if not DT
> >> bindings are DT schema now.
> >
> > We'll need the binding for the kvm host side, because there are plenty
> > of partition properties that are not discoverable (e.g. number of vCPUs).
>
> Just trying to understand the req. a bit better…
>
> The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine
> the count of partitions and their vCPUs.
>
> Is this about a guest being able to find out how many vCPUs it has?

This is about KVM finding out the information it needs in order to spawn
non-secure partitions. I don't see how it can do that with
FFA_PARTITION_INFO_GET -- who would respond?

But you're right that number of vCPUs was a bad example. We also need
information such as the entry point.

Will

2020-06-15 09:21:42

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote:
> On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote:
> > > On 10 Jun 2020, at 08:43, Will Deacon <[email protected]> wrote:
> > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
> > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> > >>> at virtual interface(VMs).
> > >>>
> > >>> Signed-off-by: Sudeep Holla <[email protected]>
> > >>> ---
> > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> > >>> 1 file changed, 47 insertions(+)
> > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
> > >>
> > >> I'm hoping this goes away if the firmware is discoverable, but if not DT
> > >> bindings are DT schema now.
> > >
> > > We'll need the binding for the kvm host side, because there are plenty
> > > of partition properties that are not discoverable (e.g. number of vCPUs).
> >
> > Just trying to understand the req. a bit better…
> >
> > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine
> > the count of partitions and their vCPUs.
> >
> > Is this about a guest being able to find out how many vCPUs it has?
>
> This is about KVM finding out the information it needs in order to spawn
> non-secure partitions. I don't see how it can do that with
> FFA_PARTITION_INFO_GET -- who would respond?

Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to
determine partition properties. It assumes that EL2 SW has already read each
partition's manifest and will reply to this ABI.

IIUC, with protected KVM, this information will have to be a part of the
manifest that the KVM host consumes.

But then, can this be made discoverable (use a SMC for discovery) at all as Rob
had originally suggested. Firmware (Secure world) has no clue and the bootloader
is long gone.

Separate topic, protected KVM does not get dibs on the manifest and it relies on
the KVM host to specify the address ranges for each partition? Does this not
mean that the KVM host can control the physical address space each partition
sees. This seems contrary to the isolation guarantees that protected KVM must
provide?

>
> But you're right that number of vCPUs was a bad example. We also need
> information such as the entry point.

Yes. From a spec perspective this should be specified in the partition manifest
unless the base address of the loaded image can be assummed to be the entry
point.

cheers,
Achin

>
> Will

2020-06-15 09:56:31

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote:
> On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote:
> > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote:
> > > > On 10 Jun 2020, at 08:43, Will Deacon <[email protected]> wrote:
> > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
> > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> > > >>> at virtual interface(VMs).
> > > >>>
> > > >>> Signed-off-by: Sudeep Holla <[email protected]>
> > > >>> ---
> > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> > > >>> 1 file changed, 47 insertions(+)
> > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
> > > >>
> > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT
> > > >> bindings are DT schema now.
> > > >
> > > > We'll need the binding for the kvm host side, because there are plenty
> > > > of partition properties that are not discoverable (e.g. number of vCPUs).
> > >
> > > Just trying to understand the req. a bit better…
> > >
> > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine
> > > the count of partitions and their vCPUs.
> > >
> > > Is this about a guest being able to find out how many vCPUs it has?
> >
> > This is about KVM finding out the information it needs in order to spawn
> > non-secure partitions. I don't see how it can do that with
> > FFA_PARTITION_INFO_GET -- who would respond?
>
> Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to
> determine partition properties. It assumes that EL2 SW has already read each
> partition's manifest and will reply to this ABI.
>
> IIUC, with protected KVM, this information will have to be a part of the
> manifest that the KVM host consumes.

The host does not consume the manifest directly -- instead, the bootloader
will use the manifest to populate these DT nodes. Again, these are *only*
for non-secure virtual partitions which are to be managed by KVM.

> But then, can this be made discoverable (use a SMC for discovery) at all as Rob
> had originally suggested. Firmware (Secure world) has no clue and the bootloader
> is long gone.

Make what discoverable?

> Separate topic, protected KVM does not get dibs on the manifest and it relies on
> the KVM host to specify the address ranges for each partition? Does this not
> mean that the KVM host can control the physical address space each partition
> sees. This seems contrary to the isolation guarantees that protected KVM must
> provide?

The host is trusted during early boot, and gives up this trust after
initialising EL2 fully. So roughly speaking, we:

* Boot at EL2 and install a shim
* Drop down to EL2 and start the host kernel
* Before some initialisation (DT parsing, SMP bringup, etc)
* Init KVM by calling back up to EL2 to install the full hypervisor

At that point, the EL1 host is no longer trusted and the last call
effectively "locks it out" from EL2.

> > But you're right that number of vCPUs was a bad example. We also need
> > information such as the entry point.
>
> Yes. From a spec perspective this should be specified in the partition manifest
> unless the base address of the loaded image can be assummed to be the entry
> point.

Right, but the format of the manifest isn't defined by the spec so I really
don't think it's something that Linux should be dealing with directly.

Will

2020-06-15 11:41:20

by Jens Wiklander

[permalink] [raw]

Subject: Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

Hi,

On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote:
> (Sorry for the delay, got distracted with some other bug fix.)
>
> On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote:
> > Hi Sudeep, [+Fuad, Andrew and Ard]
> >
> > (To other interested readers: if you haven't seen it, the FF-A spec is here:
> > https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf
> > since this discussion makes no sense without that, and a tiny bit of sense
> > with it. It used to be called "SPCI" but it was recently renamed.)
> >
>
> Thanks for adding all interested parties.
>
> > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote:
> > > Sorry for posting in the middle of merge window and I must have done
> > > this last week itself. This is not the driver I had thought about posting
> > > last week. After I started cleaning up and looking at Will's KVM prototype[1]
> > > for PSA FF-A (previously known as SPCI),
> >
> > Yes, I need to do the Big Rename at some point. Joy.
> >
>
> ????
>
> > > I got more doubts on alignment and dropped huge chunk of interface APIs in
> > > the driver in order to keep it simple, and get aligned more with that
> > > prototype and avoid scanning lots of code unnecessary.
> >
> > You also dropped most of the code, so this doesn't really do anything in
> > its current form ;)
> >
>
> Yes, it was intentional ????
>
> > > Here are few things to clarify:
> > >
> > > 1. DT bindings
> > > ---------------
> > > I was initially against adding bindings for Tx/Rx buffers for
> > > partitions. As per the spec, an endpoint could allocate the
> > > buffer pair and use the FFA_RXTX_MAP interface to map it with the
> > > Hypervisor(KVM here). However looking at the prototype and also
> > > I remember you mentioning that it is not possible to manage buffers
> > > in that way. Please confirm if you plan to add the buffer details
> > > fetcthing them through ioctls in KVM and adding them to VM DT nodes
> > > in KVM userspace. I will update the bindings accordingly.
> >
> > I think it's useful to have a mode of operation where the hypervisor
> > allocates the RX/TX buffers and advertises them in the DT. However, we
> > can always add this later, so there's no need to have it in the binding
> > from the start. Best start as simple as possible, I reckon.
> >
>
> OK
>
> > Setting the static RX/TX buffer allocation aside, why is a DT node needed
> > at all for the case where Linux is running purely as an FF-A client? I
> > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES,
> > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away
> > without a binding at all for the client case.
> >
>
> Agreed, I added for RxTx buffers and initially to build the parent/child
> hierarchy for all users of the driver. Initially I was assuming only
> in-kernel users and now I agree we should avoid any in kernel users if
> possible.
>
> One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
> information to the caller. So we need to have established buffers before
> that and one of the reason you don't find that in this RFC. I dropped that
> too which I wanted initially.
>
> > > 2. Driver
> > > ---------
> > > a. Support for multiple partitions in a VM
> > > ------------------------------------------
> > > I am not sure if there is need for supporting multiple partitions
> > > within a VM. It should be possible to do so as I expect to create
> > > device for each partition entry under arm-psa-ffa devicetree node.
> > > However, I don't want to assume something that will never be a
> > > usecase. However I don't think this will change must of the
> > > abstraction as we need to keep the interface API implementation
> > > separate to support different partitions on various platforms.
> >
> > I think Ard has a case for something like this, where a VM actually consists
> > of multiple partitions so that S-EL0 services can be provided from NS-EL0.
> > However, he probably wants that for a dynamically created VM, so we'd
> > need a way to instantiate an FFA namespace for the VM. Maybe that can be
> > done entirely in userspace by the VMM...
> >
>
> Interesting...
>
> > > b. SMCCC interface
> > > ------------------
> > > This is something I messed up completely while trying to add
> > > support for SMCCC v1.2. It now supports x0-x17 as parameter
> > > registers(input) and return registers(output). I started simple
> > > with x0-x7 as both input and output as PSA FF-A needs that at
> > > most. But extending to x0-x17 then became with messy in my
> > > implementation. That's the reason I dropped it completely
> > > here and thought of checking it first.
> > >
> > > Do we need to extend the optimisations that were done to handle
> > > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
> > > as both input and ouput. Hyper-V guys need full x0-x17 support.
> > >
> > > I need some guidance as what is the approach preferred ?
> >
> > I think we can start off with x0-x7 and extend if later if we need to.
> >
>
> Sure
>
> > > 3. Partitions
> > > -------------
> > > I am not sure if we have a full define partition that we plan to
> > > push upstream. Without one, we can have a sample/example partition
> > > to test all the interface APIs, but is that fine with respect to
> > > what we want upstream ? Any other thoughts that helps to test the
> > > driver ?
> >
> > I think that's the best you can do for now. We can probably help with
> > testing as our stuff gets off the ground.
> >
>
> OK
>
> > > Sorry for long email and too many questions, but I thought it is easier
> > > this way to begin with than throwing huge code implementing loads of APIs
> > > with no users(expect example partition) especially that I am posting this
> > > during merge window.
> >
> > No problem. Maybe it would help if I described roughly what we were thinking
> > of doing for KVM (this is open for discussion, of course):
> >
> > 1. Describe KVM-managed partitions in the DT, along the lines of [1]
> > 2. Expose each partition as a file to userspace. E.g.:
> >
> > /dev/spci/:
> >
> > self
> > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8
> > 49f65057-d002-4ae2-b4ee-d31c7940a13d
> >
> > Here, self would be a symlink to the host uuid. The host uuid file
> > would implement FFA_MEM operations using an ioctl(), so you could,
> > for example, share a user buffer with multiple partitions by issuing
> > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions
> > as arguments. Messaging would be implemented as ioctl()s on the
> > partition uuid files themselves.
> >
>
> OK, IIUC that covers mostly KVM implementation. We still need a way to
> share the RxTx buffer info to the partitions and DT/ACPI(?) is one
> possible way. Based on you comment about not needing DT node, do you have
> any other way to communicate the buffer info to the partitions ?
>
> > 3. We'll need some (all?) of these patches to unmap memory from the host
> > when necessary:
> >
> > https://lwn.net/Articles/821215/
> >
> > (for nVHE, we'll have a stage-2 for the host so we can unmap there as
> > well)
> >
>
> Sounds more fun.
>
> > For communicating with partitions that are not managed by KVM (e.g. trusted
> > applications), it's not clear to me how much of that will be handled in
> > kernel or user. I think it would still be worth exposing the partitions as
> > files, but perhaps having them root only or just returning -EPERM for the
> > ioctl() if a kernel driver has claimed the partition as its own? Ideally,
> > FF-A would allow us to transition some of the Trusted OS interfacing code
> > out to userspace, but I don't know how realistic that is.
> >
>
> Ah good, so we can still manage in-kernel users this way but we need to
> provide interface to such a driver which I agree that we need to avoid
> if possible.

The OP-TEE driver is an in-kernel user, I don't see that we can migrate
that to user space in the nearest future. In fact I'm not sure it would
make sense since we have a kernel internal interface which is used by
some drivers.

Cheers,
Jens

2020-06-15 11:47:36

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote:
> On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote:
> > On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote:
> > > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote:
> > > > > On 10 Jun 2020, at 08:43, Will Deacon <[email protected]> wrote:
> > > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote:
> > > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote:
> > > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
> > > > >>> at virtual interface(VMs).
> > > > >>>
> > > > >>> Signed-off-by: Sudeep Holla <[email protected]>
> > > > >>> ---
> > > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
> > > > >>> 1 file changed, 47 insertions(+)
> > > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
> > > > >>
> > > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT
> > > > >> bindings are DT schema now.
> > > > >
> > > > > We'll need the binding for the kvm host side, because there are plenty
> > > > > of partition properties that are not discoverable (e.g. number of vCPUs).
> > > >
> > > > Just trying to understand the req. a bit better…
> > > >
> > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine
> > > > the count of partitions and their vCPUs.
> > > >
> > > > Is this about a guest being able to find out how many vCPUs it has?
> > >
> > > This is about KVM finding out the information it needs in order to spawn
> > > non-secure partitions. I don't see how it can do that with
> > > FFA_PARTITION_INFO_GET -- who would respond?
> >
> > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to
> > determine partition properties. It assumes that EL2 SW has already read each
> > partition's manifest and will reply to this ABI.
> >
> > IIUC, with protected KVM, this information will have to be a part of the
> > manifest that the KVM host consumes.
>
> The host does not consume the manifest directly -- instead, the bootloader
> will use the manifest to populate these DT nodes. Again, these are *only*
> for non-secure virtual partitions which are to be managed by KVM.

Yes. Understand and agree. Manifest is an overloaded term. I was using it to
describe the DT nodes that the host will consume.

>
> > But then, can this be made discoverable (use a SMC for discovery) at all as Rob
> > had originally suggested. Firmware (Secure world) has no clue and the bootloader
> > is long gone.
>
> Make what discoverable?

I thought the original question was to make partition properties discoverable
instead of relying on DT nodes. I might have misunderstood. Looks like we are on
the same page in any case :o)

>
> > Separate topic, protected KVM does not get dibs on the manifest and it relies on
> > the KVM host to specify the address ranges for each partition? Does this not
> > mean that the KVM host can control the physical address space each partition
> > sees. This seems contrary to the isolation guarantees that protected KVM must
> > provide?
>
> The host is trusted during early boot, and gives up this trust after
> initialising EL2 fully. So roughly speaking, we:
>
> * Boot at EL2 and install a shim
> * Drop down to EL2 and start the host kernel
> * Before some initialisation (DT parsing, SMP bringup, etc)
> * Init KVM by calling back up to EL2 to install the full hypervisor
>
> At that point, the EL1 host is no longer trusted and the last call
> effectively "locks it out" from EL2.

Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition
by the Host. My main concern is if PKVM must trust the Host to provide the
correct physical address space ranges for a partition?

I guess your point is this is not a problem since PKVM can lock the Host out of
those address ranges in any case?

It is a bit counter intuitive that the Host gets to see and potentially
manipulate information that was verified and extracted by the bootloader from
the partition's manifest. This hapens before PKVM sees the same
information. Can't put my finger on what could go wrong though. Depends upon the
threat model too!

>
> > > But you're right that number of vCPUs was a bad example. We also need
> > > information such as the entry point.
> >
> > Yes. From a spec perspective this should be specified in the partition manifest
> > unless the base address of the loaded image can be assummed to be the entry
> > point.
>
> Right, but the format of the manifest isn't defined by the spec so I really
> don't think it's something that Linux should be dealing with directly.

Agree.

cheers,
Achin
>
> Will

2020-06-15 12:00:05

[permalink] [raw]

Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

On Mon, Jun 15, 2020 at 12:42:20PM +0100, Achin Gupta wrote:
> On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote:
> > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote:
> > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to
> > > determine partition properties. It assumes that EL2 SW has already read each
> > > partition's manifest and will reply to this ABI.
> > >
> > > IIUC, with protected KVM, this information will have to be a part of the
> > > manifest that the KVM host consumes.
> >
> > The host does not consume the manifest directly -- instead, the bootloader
> > will use the manifest to populate these DT nodes. Again, these are *only*
> > for non-secure virtual partitions which are to be managed by KVM.
>
> Yes. Understand and agree. Manifest is an overloaded term. I was using it to
> describe the DT nodes that the host will consume.

Hmm, I think that conflates two things though because only the partitions
managed by KVM will have DT nodes.

> > > Separate topic, protected KVM does not get dibs on the manifest and it relies on
> > > the KVM host to specify the address ranges for each partition? Does this not
> > > mean that the KVM host can control the physical address space each partition
> > > sees. This seems contrary to the isolation guarantees that protected KVM must
> > > provide?
> >
> > The host is trusted during early boot, and gives up this trust after
> > initialising EL2 fully. So roughly speaking, we:
> >
> > * Boot at EL2 and install a shim
> > * Drop down to EL2 and start the host kernel
> > * Before some initialisation (DT parsing, SMP bringup, etc)
> > * Init KVM by calling back up to EL2 to install the full hypervisor
> >
> > At that point, the EL1 host is no longer trusted and the last call
> > effectively "locks it out" from EL2.
>
> Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition
> by the Host. My main concern is if PKVM must trust the Host to provide the
> correct physical address space ranges for a partition?

Yes, but that all happens as part of KVM initialisation: the host parses
the DT nodes and memory reservations, and then passes this information
up to EL2.

> I guess your point is this is not a problem since PKVM can lock the Host out of
> those address ranges in any case?

It has to do this, regardless of how they are probed. Once KVM has
initialised, the host will have a stage-2 which limits it to the memory that
it is allowed to access.

> It is a bit counter intuitive that the Host gets to see and potentially
> manipulate information that was verified and extracted by the bootloader from
> the partition's manifest. This hapens before PKVM sees the same
> information. Can't put my finger on what could go wrong though. Depends upon the
> threat model too!

I think you're trying too hard to separate the host from the EL2 code during
early boot. Don't forget -- this is all part of the same binary payload that
is loaded and initially run at EL2. Having the host take care of early boot
/significantly/ reduces the amount of code at EL2, which has a very
clear security benefit.

Will

2020-06-15 16:50:46