* [PATCH v19 1/7] Documentation/firmware: add imx/se to other_interfaces
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
@ 2025-09-26 21:09 ` Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 2/7] dt-bindings: arm: fsl: add imx-se-fw binding doc Pankaj Gupta
` (7 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-09-26 21:09 UTC (permalink / raw)
To: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel
Documents i.MX SoC's Service layer and C_DEV driver for selected SoC(s)
that contains the NXP hardware IP(s) for Secure Enclaves(se) like:
- NXP EdgeLock Enclave on i.MX93 & i.MX8ULP
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
---
changes from v18 to 19
- Added 9 lines to the Introduction from line 73-82.
---
.../driver-api/firmware/other_interfaces.rst | 131 +++++++++++++++++++++
1 file changed, 131 insertions(+)
diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
index 06ac89adaafb..2a7d7100fdd4 100644
--- a/Documentation/driver-api/firmware/other_interfaces.rst
+++ b/Documentation/driver-api/firmware/other_interfaces.rst
@@ -49,3 +49,134 @@ of the requests on to a secure monitor (EL3).
.. kernel-doc:: drivers/firmware/stratix10-svc.c
:export:
+
+NXP Secure Enclave Firmware Interface
+=====================================
+
+Introduction
+------------
+The NXP's i.MX HW IP like EdgeLock Enclave, V2X etc., creates an embedded secure
+enclave within the SoC boundary to enable features like
+ - Hardware Security Module (HSM)
+ - Security Hardware Extension (SHE)
+ - Vehicular to Anything (V2X)
+
+Each of the above feature is enabled through dedicated NXP H/W IP on the SoC.
+On a single SoC, multiple hardware IP (or can say more than one secure enclave)
+can exist.
+
+NXP SoCs enabled with the such secure enclaves(SEs) IPs are:
+i.MX93, i.MX8ULP
+
+To communicate with one or more co-existing SE(s) on SoC, there is/are dedicated
+messaging units(MU) per SE. Each co-existing SE can have one or multiple exclusive
+MUs, dedicated to itself. None of the MU is shared between two SEs. Communication
+of the MU is realized using the mailbox driver. Each secure enclave can cater to
+multiple clients by virtue of these exclusive MUs. Also, they can distinguish
+transactions originating from these clients based on the MU used and core security
+state. The communication between the clients and secure enclaves is in form of
+command/response mechanism. Each client could expose specific set of secure enclave
+features to the higher layers, based on the commands supported by that client. For
+example, the secure enclave could simultaneously support an OPTEE TA and Linux
+middleware as clients. Each of these clients can expose specific set of secure
+enclave features based on the command set supported by them.
+
+NXP Secure Enclave(SE) Interface
+--------------------------------
+Although MU(s) is/are not shared between SE(s). But for SoC like i.MX95 which has
+multiple SE(s) like HSM, V2X-HSM, V2X-SHE; all the SE(s) and their interfaces 'se-if'
+that is/are dedicated to a particular SE will be enumerated and provisioned using the
+single compatible node("fsl,imx95-se").
+
+Each 'se-if' comprise of twp layers:
+- (C_DEV Layer) User-Space software-access interface.
+- (Service Layer) OS-level software-access interface.
+
+::
+ +--------------------------------------------+
+ | Character Device(C_DEV) |
+ | |
+ | +---------+ +---------+ +---------+ |
+ | | misc #1 | | misc #2 | ... | misc #n | |
+ | | dev | | dev | | dev | |
+ | +---------+ +---------+ +---------+ |
+ | +-------------------------+ |
+ | | Misc. Dev Synchr. Logic | |
+ | +-------------------------+ |
+ | |
+ +--------------------------------------------+
+
+ +--------------------------------------------+
+ | Service Layer |
+ | |
+ | +-----------------------------+ |
+ | | Message Serialization Logic | |
+ | +-----------------------------+ |
+ | +---------------+ |
+ | | imx-mailbox | |
+ | | mailbox.c | |
+ | +---------------+ |
+ | |
+ +--------------------------------------------+
+
+- service layer:
+ This layer is responsible for ensuring the communication protocol that is defined
+ for communication with firmware.
+
+ FW Communication protocol ensures two things:
+ - Serializing the messages to be sent over an MU.
+
+ - FW can handle one command message at a time.
+
+- c_dev:
+ This layer offers character device contexts, created as '/dev/<se>_mux_chx'.
+ Using these multiple device contexts that are getting multiplexed over a single MU,
+ userspace application(s) can call fops like write/read to send the command message,
+ and read back the command response message to/from Firmware.
+ fops like read & write use the above defined service layer API(s) to communicate with
+ Firmware.
+
+ Misc-device(/dev/<se>_mux_chn) synchronization protocol:
+::
+
+ Non-Secure + Secure
+ |
+ |
+ +---------+ +-------------+ |
+ | se_fw.c +<---->+imx-mailbox.c| |
+ | | | mailbox.c +<-->+------+ +------+
+ +---+-----+ +-------------+ | MU X +<-->+ ELE |
+ | +------+ +------+
+ +----------------+ |
+ | | |
+ v v |
+ logical logical |
+ receiver waiter |
+ + + |
+ | | |
+ | | |
+ | +----+------+ |
+ | | | |
+ | | | |
+ device_ctx device_ctx device_ctx |
+ |
+ User 0 User 1 User Y |
+ +------+ +------+ +------+ |
+ |misc.c| |misc.c| |misc.c| |
+ kernel space +------+ +------+ +------+ |
+ |
+ +------------------------------------------------------ |
+ | | | |
+ userspace /dev/ele_muXch0 | | |
+ /dev/ele_muXch1 | |
+ /dev/ele_muXchY |
+ |
+
+When a user sends a command to the firmware, it registers its device_ctx
+as waiter of a response from firmware.
+
+Enclave's Firmware owns the storage management, over Linux filesystem.
+For this c_dev provisions a dedicated slave device called "receiver".
+
+.. kernel-doc:: drivers/firmware/imx/se_fw.c
+ :export:
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v19 2/7] dt-bindings: arm: fsl: add imx-se-fw binding doc
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 1/7] Documentation/firmware: add imx/se to other_interfaces Pankaj Gupta
@ 2025-09-26 21:09 ` Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 3/7] firmware: imx: add driver for NXP EdgeLock Enclave Pankaj Gupta
` (6 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-09-26 21:09 UTC (permalink / raw)
To: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel
The NXP security hardware IP(s) like: i.MX EdgeLock Enclave, V2X etc.,
creates an embedded secure enclave within the SoC boundary to enable
features like:
- HSM
- SHE
- V2X
Secure-Enclave(s) communication interface are typically via message
unit, i.e., based on mailbox linux kernel driver. This driver enables
communication ensuring well defined message sequence protocol between
Application Core and enclave's firmware.
Driver configures multiple misc-device on the MU, for multiple
user-space applications, to be able to communicate over single MU.
It exists on some i.MX processors. e.g. i.MX8ULP, i.MX93 etc.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/firmware/fsl,imx-se.yaml | 91 ++++++++++++++++++++++
1 file changed, 91 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/fsl,imx-se.yaml b/Documentation/devicetree/bindings/firmware/fsl,imx-se.yaml
new file mode 100644
index 000000000000..fa81adbf9b80
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/fsl,imx-se.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/fsl,imx-se.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX HW Secure Enclave(s) EdgeLock Enclave
+
+maintainers:
+ - Pankaj Gupta <pankaj.gupta@nxp.com>
+
+description: |
+ NXP's SoC may contain one or multiple embedded secure-enclave HW
+ IP(s) like i.MX EdgeLock Enclave, V2X etc. These NXP's HW IP(s)
+ enables features like
+ - Hardware Security Module (HSM),
+ - Security Hardware Extension (SHE), and
+ - Vehicular to Anything (V2X)
+
+ Communication interface to the secure-enclaves(se) is based on the
+ messaging unit(s).
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8ulp-se-ele-hsm
+ - fsl,imx93-se-ele-hsm
+ - fsl,imx95-se-ele-hsm
+
+ mboxes:
+ items:
+ - description: mailbox phandle to send message to se firmware
+ - description: mailbox phandle to receive message from se firmware
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ memory-region:
+ maxItems: 1
+
+ sram:
+ maxItems: 1
+
+required:
+ - compatible
+ - mboxes
+ - mbox-names
+
+allOf:
+ # memory-region
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8ulp-se-ele-hsm
+ - fsl,imx93-se-ele-hsm
+ then:
+ required:
+ - memory-region
+ else:
+ properties:
+ memory-region: false
+
+ # sram
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8ulp-se-ele-hsm
+ then:
+ required:
+ - sram
+
+ else:
+ properties:
+ sram: false
+
+additionalProperties: false
+
+examples:
+ - |
+ secure-enclave {
+ compatible = "fsl,imx95-se-ele-hsm";
+ mboxes = <&ele_mu0 0 0>, <&ele_mu0 1 0>;
+ mbox-names = "tx", "rx";
+ };
+...
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v19 3/7] firmware: imx: add driver for NXP EdgeLock Enclave
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 1/7] Documentation/firmware: add imx/se to other_interfaces Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 2/7] dt-bindings: arm: fsl: add imx-se-fw binding doc Pankaj Gupta
@ 2025-09-26 21:09 ` Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 4/7] firmware: imx: device context dedicated to priv Pankaj Gupta
` (5 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-09-26 21:09 UTC (permalink / raw)
To: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel,
Frank Li
Add driver for enabling MU based communication interface to secure-enclave.
NXP hardware IP(s) for secure-enclaves like Edgelock Enclave(ELE), are
embedded in the SoC to support the features like HSM, SHE & V2X, using
message based communication interface.
The secure enclave FW communicates with Linux over single or multiple
dedicated messaging unit(MU) based interface(s).
Exists on i.MX SoC(s) like i.MX8ULP, i.MX93, i.MX95 etc.
For i.MX9x SoC(s) there is at least one dedicated ELE MU(s) for each
world - Linux(one or more) and OPTEE-OS (one or more).
Other dependent kernel drivers will be:
- NVMEM: that supports non-volatile devices like EFUSES,
managed by NXP's secure-enclave.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
Changes from v18 to v19
- Update the commit message for " For i.MX9x SoC(s) there is at least one
dedicated ELE MU(s) for each world - Linux(one or more) and OPTEE-OS (one
or more), that needs to be shared between them."
---
drivers/firmware/imx/Kconfig | 13 ++
drivers/firmware/imx/Makefile | 2 +
drivers/firmware/imx/ele_base_msg.c | 269 ++++++++++++++++++++++++
drivers/firmware/imx/ele_base_msg.h | 95 +++++++++
drivers/firmware/imx/ele_common.c | 333 ++++++++++++++++++++++++++++++
drivers/firmware/imx/ele_common.h | 45 ++++
drivers/firmware/imx/se_ctrl.c | 401 ++++++++++++++++++++++++++++++++++++
drivers/firmware/imx/se_ctrl.h | 86 ++++++++
include/linux/firmware/imx/se_api.h | 14 ++
9 files changed, 1258 insertions(+)
diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
index 127ad752acf8..5fe96299b704 100644
--- a/drivers/firmware/imx/Kconfig
+++ b/drivers/firmware/imx/Kconfig
@@ -55,3 +55,16 @@ config IMX_SCMI_MISC_DRV
core that could provide misc functions such as board control.
This driver can also be built as a module.
+
+config IMX_SEC_ENCLAVE
+ tristate "i.MX Embedded Secure Enclave - EdgeLock Enclave Firmware driver."
+ depends on IMX_MBOX && ARCH_MXC && ARM64
+ select FW_LOADER
+ default m if ARCH_MXC
+
+ help
+ Exposes APIs supported by the iMX Secure Enclave HW IP called:
+ - EdgeLock Enclave Firmware (for i.MX8ULP, i.MX93),
+ like base, HSM, V2X & SHE using the SAB protocol via the shared Messaging
+ Unit. This driver exposes these interfaces via a set of file descriptors
+ allowing to configure shared memory, send and receive messages.
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 3bbaffa6e347..4412b15846b1 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -4,3 +4,5 @@ obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o imx-scu-soc.o
obj-${CONFIG_IMX_SCMI_CPU_DRV} += sm-cpu.o
obj-${CONFIG_IMX_SCMI_MISC_DRV} += sm-misc.o
obj-${CONFIG_IMX_SCMI_LMM_DRV} += sm-lmm.o
+sec_enclave-objs = se_ctrl.o ele_common.o ele_base_msg.o
+obj-${CONFIG_IMX_SEC_ENCLAVE} += sec_enclave.o
diff --git a/drivers/firmware/imx/ele_base_msg.c b/drivers/firmware/imx/ele_base_msg.c
new file mode 100644
index 000000000000..a070acbd895c
--- /dev/null
+++ b/drivers/firmware/imx/ele_base_msg.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2025 NXP
+ */
+
+#include <linux/types.h>
+
+#include <linux/completion.h>
+#include <linux/dma-mapping.h>
+#include <linux/genalloc.h>
+
+#include "ele_base_msg.h"
+#include "ele_common.h"
+
+#define FW_DBG_DUMP_FIXED_STR "ELE"
+
+int ele_get_info(struct se_if_priv *priv, struct ele_dev_info *s_info)
+{
+ struct se_api_msg *tx_msg __free(kfree) = NULL;
+ struct se_api_msg *rx_msg __free(kfree) = NULL;
+ dma_addr_t get_info_addr = 0;
+ u32 *get_info_data = NULL;
+ int ret = 0;
+
+ if (!priv)
+ return -EINVAL;
+
+ memset(s_info, 0x0, sizeof(*s_info));
+
+ tx_msg = kzalloc(ELE_GET_INFO_REQ_MSG_SZ, GFP_KERNEL);
+ if (!tx_msg)
+ return -ENOMEM;
+
+ rx_msg = kzalloc(ELE_GET_INFO_RSP_MSG_SZ, GFP_KERNEL);
+ if (!rx_msg)
+ return -ENOMEM;
+
+ if (priv->mem_pool)
+ get_info_data = gen_pool_dma_alloc(priv->mem_pool,
+ ELE_GET_INFO_BUFF_SZ,
+ &get_info_addr);
+ else
+ get_info_data = dma_alloc_coherent(priv->dev,
+ ELE_GET_INFO_BUFF_SZ,
+ &get_info_addr,
+ GFP_KERNEL);
+ if (!get_info_data) {
+ dev_dbg(priv->dev,
+ "%s: Failed to allocate get_info_addr.", __func__);
+ return -ENOMEM;
+ }
+
+ ret = se_fill_cmd_msg_hdr(priv, (struct se_msg_hdr *)&tx_msg->header,
+ ELE_GET_INFO_REQ, ELE_GET_INFO_REQ_MSG_SZ,
+ true);
+ if (ret)
+ goto exit;
+
+ tx_msg->data[0] = upper_32_bits(get_info_addr);
+ tx_msg->data[1] = lower_32_bits(get_info_addr);
+ tx_msg->data[2] = sizeof(*s_info);
+ ret = ele_msg_send_rcv(priv, tx_msg, ELE_GET_INFO_REQ_MSG_SZ, rx_msg,
+ ELE_GET_INFO_RSP_MSG_SZ);
+ if (ret < 0)
+ goto exit;
+
+ ret = se_val_rsp_hdr_n_status(priv, rx_msg, ELE_GET_INFO_REQ,
+ ELE_GET_INFO_RSP_MSG_SZ, true);
+
+ memcpy(s_info, get_info_data, sizeof(*s_info));
+
+exit:
+ if (priv->mem_pool)
+ gen_pool_free(priv->mem_pool, (u64)get_info_data,
+ ELE_GET_INFO_BUFF_SZ);
+ else
+ dma_free_coherent(priv->dev, ELE_GET_INFO_BUFF_SZ,
+ get_info_data, get_info_addr);
+
+ return ret;
+}
+
+int ele_fetch_soc_info(struct se_if_priv *priv, void *data)
+{
+ return ele_get_info(priv, data);
+}
+
+int ele_ping(struct se_if_priv *priv)
+{
+ struct se_api_msg *tx_msg __free(kfree) = NULL;
+ struct se_api_msg *rx_msg __free(kfree) = NULL;
+ int ret = 0;
+
+ if (!priv)
+ return -EINVAL;
+
+ tx_msg = kzalloc(ELE_PING_REQ_SZ, GFP_KERNEL);
+ if (!tx_msg)
+ return -ENOMEM;
+
+ rx_msg = kzalloc(ELE_PING_RSP_SZ, GFP_KERNEL);
+ if (!rx_msg)
+ return -ENOMEM;
+
+ ret = se_fill_cmd_msg_hdr(priv, (struct se_msg_hdr *)&tx_msg->header,
+ ELE_PING_REQ, ELE_PING_REQ_SZ, true);
+ if (ret) {
+ dev_err(priv->dev, "Error: se_fill_cmd_msg_hdr failed.");
+ return ret;
+ }
+
+ ret = ele_msg_send_rcv(priv, tx_msg, ELE_PING_REQ_SZ, rx_msg,
+ ELE_PING_RSP_SZ);
+ if (ret < 0)
+ return ret;
+
+ ret = se_val_rsp_hdr_n_status(priv, rx_msg, ELE_PING_REQ,
+ ELE_PING_RSP_SZ, true);
+
+ return ret;
+}
+
+int ele_service_swap(struct se_if_priv *priv,
+ phys_addr_t addr,
+ u32 addr_size, u16 flag)
+{
+ struct se_api_msg *tx_msg __free(kfree) = NULL;
+ struct se_api_msg *rx_msg __free(kfree) = NULL;
+ int ret = 0;
+
+ if (!priv)
+ return -EINVAL;
+
+ tx_msg = kzalloc(ELE_SERVICE_SWAP_REQ_MSG_SZ, GFP_KERNEL);
+ if (!tx_msg)
+ return -ENOMEM;
+
+ rx_msg = kzalloc(ELE_SERVICE_SWAP_RSP_MSG_SZ, GFP_KERNEL);
+ if (!rx_msg)
+ return -ENOMEM;
+
+ ret = se_fill_cmd_msg_hdr(priv, (struct se_msg_hdr *)&tx_msg->header,
+ ELE_SERVICE_SWAP_REQ,
+ ELE_SERVICE_SWAP_REQ_MSG_SZ, true);
+ if (ret)
+ return ret;
+
+ tx_msg->data[0] = flag;
+ tx_msg->data[1] = addr_size;
+ tx_msg->data[2] = ELE_NONE_VAL;
+ tx_msg->data[3] = lower_32_bits(addr);
+ tx_msg->data[4] = se_get_msg_chksum((u32 *)&tx_msg[0],
+ ELE_SERVICE_SWAP_REQ_MSG_SZ);
+ if (!tx_msg->data[4])
+ return -EINVAL;
+
+ ret = ele_msg_send_rcv(priv, tx_msg, ELE_SERVICE_SWAP_REQ_MSG_SZ,
+ rx_msg, ELE_SERVICE_SWAP_RSP_MSG_SZ);
+ if (ret < 0)
+ return ret;
+
+ ret = se_val_rsp_hdr_n_status(priv, rx_msg, ELE_SERVICE_SWAP_REQ,
+ ELE_SERVICE_SWAP_RSP_MSG_SZ, true);
+ if (ret)
+ return ret;
+
+ if (flag == ELE_IMEM_EXPORT)
+ ret = rx_msg->data[1];
+ else
+ ret = 0;
+
+ return ret;
+}
+
+int ele_fw_authenticate(struct se_if_priv *priv, phys_addr_t contnr_addr,
+ phys_addr_t img_addr)
+{
+ struct se_api_msg *tx_msg __free(kfree) = NULL;
+ struct se_api_msg *rx_msg __free(kfree) = NULL;
+ int ret = 0;
+
+ if (!priv)
+ return -EINVAL;
+
+ tx_msg = kzalloc(ELE_FW_AUTH_REQ_SZ, GFP_KERNEL);
+ if (!tx_msg)
+ return -ENOMEM;
+
+ rx_msg = kzalloc(ELE_FW_AUTH_RSP_MSG_SZ, GFP_KERNEL);
+ if (!rx_msg)
+ return -ENOMEM;
+
+ ret = se_fill_cmd_msg_hdr(priv, (struct se_msg_hdr *)&tx_msg->header,
+ ELE_FW_AUTH_REQ, ELE_FW_AUTH_REQ_SZ, true);
+ if (ret)
+ return ret;
+
+ tx_msg->data[0] = lower_32_bits(contnr_addr);
+ tx_msg->data[1] = upper_32_bits(contnr_addr);
+ tx_msg->data[2] = img_addr;
+
+ ret = ele_msg_send_rcv(priv, tx_msg, ELE_FW_AUTH_REQ_SZ, rx_msg,
+ ELE_FW_AUTH_RSP_MSG_SZ);
+ if (ret < 0)
+ return ret;
+
+ ret = se_val_rsp_hdr_n_status(priv, rx_msg, ELE_FW_AUTH_REQ,
+ ELE_FW_AUTH_RSP_MSG_SZ, true);
+ return ret;
+}
+
+int ele_debug_dump(struct se_if_priv *priv)
+{
+ struct se_api_msg *tx_msg __free(kfree) = NULL;
+ struct se_api_msg *rx_msg __free(kfree) = NULL;
+ bool keep_logging;
+ int msg_ex_cnt;
+ int ret = 0;
+ int i;
+
+ if (!priv)
+ return -EINVAL;
+
+ tx_msg = kzalloc(ELE_DEBUG_DUMP_REQ_SZ, GFP_KERNEL);
+ if (!tx_msg)
+ return -ENOMEM;
+
+ rx_msg = kzalloc(ELE_DEBUG_DUMP_RSP_SZ, GFP_KERNEL);
+ if (!rx_msg)
+ return -ENOMEM;
+
+ ret = se_fill_cmd_msg_hdr(priv, &tx_msg->header, ELE_DEBUG_DUMP_REQ,
+ ELE_DEBUG_DUMP_REQ_SZ, true);
+ if (ret)
+ return ret;
+
+ msg_ex_cnt = 0;
+ do {
+ memset(rx_msg, 0x0, ELE_DEBUG_DUMP_RSP_SZ);
+
+ ret = ele_msg_send_rcv(priv, tx_msg, ELE_DEBUG_DUMP_REQ_SZ,
+ rx_msg, ELE_DEBUG_DUMP_RSP_SZ);
+ if (ret < 0)
+ return ret;
+
+ ret = se_val_rsp_hdr_n_status(priv, rx_msg, ELE_DEBUG_DUMP_REQ,
+ ELE_DEBUG_DUMP_RSP_SZ, true);
+ if (ret) {
+ dev_err(priv->dev, "Dump_Debug_Buffer Error: %x.", ret);
+ break;
+ }
+ keep_logging = (rx_msg->header.size >= (ELE_DEBUG_DUMP_RSP_SZ >> 2) &&
+ msg_ex_cnt < ELE_MAX_DBG_DMP_PKT);
+
+ rx_msg->header.size -= 2;
+
+ if (rx_msg->header.size > 4)
+ rx_msg->header.size--;
+
+ for (i = 0; i < rx_msg->header.size; i += 2)
+ dev_info(priv->dev, "%s%02x_%02x: 0x%08x 0x%08x",
+ FW_DBG_DUMP_FIXED_STR, msg_ex_cnt, i,
+ rx_msg->data[i + 1], rx_msg->data[i + 2]);
+
+ msg_ex_cnt++;
+ } while (keep_logging);
+
+ return ret;
+}
diff --git a/drivers/firmware/imx/ele_base_msg.h b/drivers/firmware/imx/ele_base_msg.h
new file mode 100644
index 000000000000..8e5b015e99a2
--- /dev/null
+++ b/drivers/firmware/imx/ele_base_msg.h
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2025 NXP
+ *
+ * Header file for the EdgeLock Enclave Base API(s).
+ */
+
+#ifndef ELE_BASE_MSG_H
+#define ELE_BASE_MSG_H
+
+#include <linux/device.h>
+#include <linux/types.h>
+
+#include "se_ctrl.h"
+
+#define ELE_NONE_VAL 0x0
+
+#define ELE_GET_INFO_REQ 0xda
+#define ELE_GET_INFO_REQ_MSG_SZ 0x10
+#define ELE_GET_INFO_RSP_MSG_SZ 0x08
+
+#define MAX_UID_SIZE (16)
+#define DEV_GETINFO_ROM_PATCH_SHA_SZ (32)
+#define DEV_GETINFO_FW_SHA_SZ (32)
+#define DEV_GETINFO_OEM_SRKH_SZ (64)
+#define DEV_GETINFO_MIN_VER_MASK 0xff
+#define DEV_GETINFO_MAJ_VER_MASK 0xff00
+#define ELE_DEV_INFO_EXTRA_SZ 0x60
+
+struct dev_info {
+ u8 cmd;
+ u8 ver;
+ u16 length;
+ u16 soc_id;
+ u16 soc_rev;
+ u16 lmda_val;
+ u8 ssm_state;
+ u8 dev_atts_api_ver;
+ u8 uid[MAX_UID_SIZE];
+ u8 sha_rom_patch[DEV_GETINFO_ROM_PATCH_SHA_SZ];
+ u8 sha_fw[DEV_GETINFO_FW_SHA_SZ];
+};
+
+struct dev_addn_info {
+ u8 oem_srkh[DEV_GETINFO_OEM_SRKH_SZ];
+ u8 trng_state;
+ u8 csal_state;
+ u8 imem_state;
+ u8 reserved2;
+};
+
+struct ele_dev_info {
+ struct dev_info d_info;
+ struct dev_addn_info d_addn_info;
+};
+
+#define ELE_GET_INFO_BUFF_SZ (sizeof(struct ele_dev_info) \
+ + ELE_DEV_INFO_EXTRA_SZ)
+
+#define GET_SERIAL_NUM_FROM_UID(x, uid_word_sz) \
+ (((u64)(((u32 *)(x))[(uid_word_sz) - 1]) << 32) | ((u32 *)(x))[0])
+
+#define ELE_MAX_DBG_DMP_PKT 50
+#define ELE_DEBUG_DUMP_REQ 0x21
+#define ELE_DEBUG_DUMP_REQ_SZ 0x4
+#define ELE_DEBUG_DUMP_RSP_SZ 0x5c
+
+#define ELE_PING_REQ 0x01
+#define ELE_PING_REQ_SZ 0x04
+#define ELE_PING_RSP_SZ 0x08
+
+#define ELE_SERVICE_SWAP_REQ 0xdf
+#define ELE_SERVICE_SWAP_REQ_MSG_SZ 0x18
+#define ELE_SERVICE_SWAP_RSP_MSG_SZ 0x0c
+#define ELE_IMEM_SIZE 0x10000
+#define ELE_IMEM_STATE_OK 0xca
+#define ELE_IMEM_STATE_BAD 0xfe
+#define ELE_IMEM_STATE_WORD 0x27
+#define ELE_IMEM_STATE_MASK 0x00ff0000
+#define ELE_IMEM_EXPORT 0x1
+#define ELE_IMEM_IMPORT 0x2
+
+#define ELE_FW_AUTH_REQ 0x02
+#define ELE_FW_AUTH_REQ_SZ 0x10
+#define ELE_FW_AUTH_RSP_MSG_SZ 0x08
+
+int ele_get_info(struct se_if_priv *priv, struct ele_dev_info *s_info);
+int ele_fetch_soc_info(struct se_if_priv *priv, void *data);
+int ele_ping(struct se_if_priv *priv);
+int ele_service_swap(struct se_if_priv *priv, phys_addr_t addr,
+ u32 addr_size, u16 flag);
+int ele_fw_authenticate(struct se_if_priv *priv, phys_addr_t contnr_addr,
+ phys_addr_t img_addr);
+int ele_debug_dump(struct se_if_priv *priv);
+#endif
diff --git a/drivers/firmware/imx/ele_common.c b/drivers/firmware/imx/ele_common.c
new file mode 100644
index 000000000000..748eb09474d7
--- /dev/null
+++ b/drivers/firmware/imx/ele_common.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2025 NXP
+ */
+
+#include "ele_base_msg.h"
+#include "ele_common.h"
+
+/*
+ * se_get_msg_chksum() - to calculate checksum word by word.
+ *
+ * @msg : reference to the input msg-data.
+ * @msg_len : reference to the input msg-data length in bytes.
+ * Includes extra 4 bytes (or 1 words) chksum.
+ *
+ * This function returns the checksum calculated by ORing word by word.
+ *
+ * Return:
+ * 0: if the input length is not 4 byte aligned, or num of words < 5.
+ * chksum: calculated word by word.
+ */
+u32 se_get_msg_chksum(u32 *msg, u32 msg_len)
+{
+ u32 nb_words = msg_len / (u32)sizeof(u32);
+ u32 chksum = 0;
+ u32 i;
+
+ if (nb_words < 5)
+ return chksum;
+
+ if (msg_len % SE_MSG_WORD_SZ) {
+ pr_err("Msg-len is not 4-byte aligned.");
+ return chksum;
+ }
+
+ /* nb_words include one checksum word, so skip it. */
+ nb_words--;
+
+ for (i = 0; i < nb_words; i++)
+ chksum ^= *(msg + i);
+
+ return chksum;
+}
+
+int ele_msg_rcv(struct se_if_priv *priv, struct se_clbk_handle *se_clbk_hdl)
+{
+ unsigned long timeout;
+ int ret;
+
+ do {
+ timeout = MAX_SCHEDULE_TIMEOUT;
+
+ ret = wait_for_completion_interruptible_timeout(&se_clbk_hdl->done, timeout);
+ if (ret == -ERESTARTSYS) {
+ if (priv->waiting_rsp_clbk_hdl.rx_msg) {
+ priv->waiting_rsp_clbk_hdl.signal_rcvd = true;
+ continue;
+ }
+ ret = -EINTR;
+ break;
+ }
+ ret = se_clbk_hdl->rx_msg_sz;
+ break;
+ } while (ret < 0);
+
+ return ret;
+}
+
+int ele_msg_send(struct se_if_priv *priv,
+ void *tx_msg,
+ int tx_msg_sz)
+{
+ struct se_msg_hdr *header = tx_msg;
+ int err;
+
+ /*
+ * Check that the size passed as argument matches the size
+ * carried in the message.
+ */
+ if (header->size << 2 != tx_msg_sz) {
+ dev_err(priv->dev,
+ "User buf hdr: 0x%x, sz mismatced with input-sz (%d != %d).",
+ *(u32 *)header, header->size << 2, tx_msg_sz);
+ return -EINVAL;
+ }
+
+ err = mbox_send_message(priv->tx_chan, tx_msg);
+ if (err < 0) {
+ dev_err(priv->dev, "Error: mbox_send_message failure.\n");
+ return err;
+ }
+
+ return tx_msg_sz;
+}
+
+/* API used for send/receive blocking call. */
+int ele_msg_send_rcv(struct se_if_priv *priv, void *tx_msg, int tx_msg_sz,
+ void *rx_msg, int exp_rx_msg_sz)
+{
+ int err;
+
+ guard(mutex)(&priv->se_if_cmd_lock);
+
+ priv->waiting_rsp_clbk_hdl.rx_msg_sz = exp_rx_msg_sz;
+ priv->waiting_rsp_clbk_hdl.rx_msg = rx_msg;
+
+ err = ele_msg_send(priv, tx_msg, tx_msg_sz);
+ if (err < 0)
+ return err;
+
+ err = ele_msg_rcv(priv, &priv->waiting_rsp_clbk_hdl);
+
+ if (priv->waiting_rsp_clbk_hdl.signal_rcvd) {
+ err = -EINTR;
+ priv->waiting_rsp_clbk_hdl.signal_rcvd = false;
+ dev_err(priv->dev, "Err[0x%x]:Interrupted by signal.\n", err);
+ }
+
+ return err;
+}
+
+static bool check_hdr_exception_for_sz(struct se_if_priv *priv,
+ struct se_msg_hdr *header)
+{
+ /*
+ * List of API(s) header that can be accepte variable length
+ * response buffer.
+ */
+ if (header->command == ELE_DEBUG_DUMP_REQ &&
+ header->ver == priv->if_defs->base_api_ver &&
+ header->size >= 0 && header->size <= ELE_DEBUG_DUMP_RSP_SZ)
+ return true;
+
+ return false;
+}
+
+/*
+ * Callback called by mailbox FW, when data is received.
+ */
+void se_if_rx_callback(struct mbox_client *mbox_cl, void *msg)
+{
+ struct se_clbk_handle *se_clbk_hdl;
+ struct device *dev = mbox_cl->dev;
+ struct se_msg_hdr *header;
+ struct se_if_priv *priv;
+ u32 rx_msg_sz;
+
+ priv = dev_get_drvdata(dev);
+
+ /* The function can be called with NULL msg */
+ if (!msg) {
+ dev_err(dev, "Message is invalid\n");
+ return;
+ }
+
+ header = msg;
+ rx_msg_sz = header->size << 2;
+
+ /* Incoming command: wake up the receiver if any. */
+ if (header->tag == priv->if_defs->cmd_tag) {
+ se_clbk_hdl = &priv->cmd_receiver_clbk_hdl;
+ dev_dbg(dev, "Selecting cmd receiver for mesg header:0x%x.",
+ *(u32 *)header);
+
+ /*
+ * Pre-allocated buffer of MAX_NVM_MSG_LEN
+ * as the NVM command are initiated by FW.
+ * Size is revealed as part of this call function.
+ */
+ if (rx_msg_sz > MAX_NVM_MSG_LEN) {
+ dev_err(dev,
+ "CMD-RCVER NVM: hdr(0x%x) with different sz(%d != %d).\n",
+ *(u32 *)header, rx_msg_sz, se_clbk_hdl->rx_msg_sz);
+
+ se_clbk_hdl->rx_msg_sz = MAX_NVM_MSG_LEN;
+ }
+ se_clbk_hdl->rx_msg_sz = rx_msg_sz;
+
+ } else if (header->tag == priv->if_defs->rsp_tag) {
+ se_clbk_hdl = &priv->waiting_rsp_clbk_hdl;
+ dev_dbg(dev, "Selecting resp waiter for mesg header:0x%x.",
+ *(u32 *)header);
+
+ if (rx_msg_sz != se_clbk_hdl->rx_msg_sz &&
+ check_hdr_exception_for_sz(priv, header)) {
+ dev_err(dev,
+ "Rsp to CMD: hdr(0x%x) with different sz(%d != %d).\n",
+ *(u32 *)header, rx_msg_sz, se_clbk_hdl->rx_msg_sz);
+
+ se_clbk_hdl->rx_msg_sz = min(rx_msg_sz, se_clbk_hdl->rx_msg_sz);
+ }
+ } else {
+ dev_err(dev, "Failed to select a device for message: %.8x\n",
+ *((u32 *)header));
+ return;
+ }
+
+ memcpy(se_clbk_hdl->rx_msg, msg, se_clbk_hdl->rx_msg_sz);
+
+ /* Allow user to read */
+ complete(&se_clbk_hdl->done);
+}
+
+int se_val_rsp_hdr_n_status(struct se_if_priv *priv, struct se_api_msg *msg,
+ u8 msg_id, u8 sz, bool is_base_api)
+{
+ struct se_msg_hdr *header = &msg->header;
+ u32 status;
+
+ if (header->tag != priv->if_defs->rsp_tag) {
+ dev_err(priv->dev, "MSG[0x%x] Hdr: Resp tag mismatch. (0x%x != 0x%x)",
+ msg_id, header->tag, priv->if_defs->rsp_tag);
+ return -EINVAL;
+ }
+
+ if (header->command != msg_id) {
+ dev_err(priv->dev, "MSG Header: Cmd id mismatch. (0x%x != 0x%x)",
+ header->command, msg_id);
+ return -EINVAL;
+ }
+
+ if ((sz % 4) || (header->size != (sz >> 2) &&
+ !check_hdr_exception_for_sz(priv, header))) {
+ dev_err(priv->dev, "MSG[0x%x] Hdr: Cmd size mismatch. (0x%x != 0x%x)",
+ msg_id, header->size, (sz >> 2));
+ return -EINVAL;
+ }
+
+ if (is_base_api && header->ver != priv->if_defs->base_api_ver) {
+ dev_err(priv->dev,
+ "MSG[0x%x] Hdr: Base API Vers mismatch. (0x%x != 0x%x)",
+ msg_id, header->ver, priv->if_defs->base_api_ver);
+ return -EINVAL;
+ } else if (!is_base_api && header->ver != priv->if_defs->fw_api_ver) {
+ dev_err(priv->dev,
+ "MSG[0x%x] Hdr: FW API Vers mismatch. (0x%x != 0x%x)",
+ msg_id, header->ver, priv->if_defs->fw_api_ver);
+ return -EINVAL;
+ }
+
+ status = RES_STATUS(msg->data[0]);
+ if (status != priv->if_defs->success_tag) {
+ dev_err(priv->dev, "Command Id[%x], Response Failure = 0x%x",
+ header->command, status);
+ return -EPERM;
+ }
+
+ return 0;
+}
+
+int se_save_imem_state(struct se_if_priv *priv, struct se_imem_buf *imem)
+{
+ struct ele_dev_info s_info = {0};
+ int ret;
+
+ ret = ele_get_info(priv, &s_info);
+ if (ret) {
+ dev_err(priv->dev, "Failed to get info from ELE.\n");
+ return ret;
+ }
+
+ /* Do not save the IMEM buffer, if the current IMEM state is BAD. */
+ if (s_info.d_addn_info.imem_state == ELE_IMEM_STATE_BAD)
+ return ret;
+
+ /*
+ * EXPORT command will save encrypted IMEM to given address,
+ * so later in resume, IMEM can be restored from the given
+ * address.
+ *
+ * Size must be at least 64 kB.
+ */
+ ret = ele_service_swap(priv, imem->phyaddr, ELE_IMEM_SIZE, ELE_IMEM_EXPORT);
+ if (ret < 0) {
+ dev_err(priv->dev, "Failed to export IMEM.");
+ imem->size = 0;
+ } else {
+ dev_dbg(priv->dev,
+ "Exported %d bytes of encrypted IMEM.",
+ ret);
+ imem->size = ret;
+ }
+
+ return ret > 0 ? 0 : ret;
+}
+
+int se_restore_imem_state(struct se_if_priv *priv, struct se_imem_buf *imem)
+{
+ struct ele_dev_info s_info;
+ int ret;
+
+ /* get info from ELE */
+ ret = ele_get_info(priv, &s_info);
+ if (ret) {
+ dev_err(priv->dev, "Failed to get info from ELE.");
+ return ret;
+ }
+ imem->state = s_info.d_addn_info.imem_state;
+
+ /* Get IMEM state, if 0xFE then import IMEM if imem size is non-zero. */
+ if (s_info.d_addn_info.imem_state != ELE_IMEM_STATE_BAD || !imem->size)
+ return ret;
+
+ /*
+ * IMPORT command will restore IMEM from the given
+ * address, here size is the actual size returned by ELE
+ * during the export operation
+ */
+ ret = ele_service_swap(priv, imem->phyaddr, imem->size, ELE_IMEM_IMPORT);
+ if (ret) {
+ dev_err(priv->dev, "Failed to import IMEM");
+ return ret;
+ }
+
+ /*
+ * After importing IMEM, check if IMEM state is equal to 0xCA
+ * to ensure IMEM is fully loaded and
+ * ELE functionality can be used.
+ */
+ ret = ele_get_info(priv, &s_info);
+ if (ret) {
+ dev_err(priv->dev, "Failed to get info from ELE.");
+ return ret;
+ }
+ imem->state = s_info.d_addn_info.imem_state;
+
+ if (s_info.d_addn_info.imem_state == ELE_IMEM_STATE_OK)
+ dev_dbg(priv->dev, "Successfully restored IMEM.");
+ else
+ dev_err(priv->dev, "Failed to restore IMEM.");
+
+ return ret;
+}
diff --git a/drivers/firmware/imx/ele_common.h b/drivers/firmware/imx/ele_common.h
new file mode 100644
index 000000000000..96e987ef6f88
--- /dev/null
+++ b/drivers/firmware/imx/ele_common.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2025 NXP
+ */
+
+#ifndef __ELE_COMMON_H__
+#define __ELE_COMMON_H__
+
+#include "se_ctrl.h"
+
+#define ELE_SUCCESS_IND 0xD6
+
+#define IMX_ELE_FW_DIR "imx/ele/"
+
+u32 se_get_msg_chksum(u32 *msg, u32 msg_len);
+
+int ele_msg_rcv(struct se_if_priv *priv, struct se_clbk_handle *se_clbk_hdl);
+
+int ele_msg_send(struct se_if_priv *priv, void *tx_msg, int tx_msg_sz);
+
+int ele_msg_send_rcv(struct se_if_priv *priv, void *tx_msg, int tx_msg_sz,
+ void *rx_msg, int exp_rx_msg_sz);
+
+void se_if_rx_callback(struct mbox_client *mbox_cl, void *msg);
+
+int se_val_rsp_hdr_n_status(struct se_if_priv *priv, struct se_api_msg *msg,
+ u8 msg_id, u8 sz, bool is_base_api);
+
+/* Fill a command message header with a given command ID and length in bytes. */
+static inline int se_fill_cmd_msg_hdr(struct se_if_priv *priv, struct se_msg_hdr *hdr,
+ u8 cmd, u32 len, bool is_base_api)
+{
+ hdr->tag = priv->if_defs->cmd_tag;
+ hdr->ver = (is_base_api) ? priv->if_defs->base_api_ver : priv->if_defs->fw_api_ver;
+ hdr->command = cmd;
+ hdr->size = len >> 2;
+
+ return 0;
+}
+
+int se_save_imem_state(struct se_if_priv *priv, struct se_imem_buf *imem);
+
+int se_restore_imem_state(struct se_if_priv *priv, struct se_imem_buf *imem);
+
+#endif /*__ELE_COMMON_H__ */
diff --git a/drivers/firmware/imx/se_ctrl.c b/drivers/firmware/imx/se_ctrl.c
new file mode 100644
index 000000000000..5f978c97da4a
--- /dev/null
+++ b/drivers/firmware/imx/se_ctrl.c
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2025 NXP
+ */
+
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/dev_printk.h>
+#include <linux/dma-mapping.h>
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/firmware.h>
+#include <linux/firmware/imx/se_api.h>
+#include <linux/genalloc.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/miscdevice.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sys_soc.h>
+
+#include "ele_base_msg.h"
+#include "ele_common.h"
+#include "se_ctrl.h"
+
+#define MAX_SOC_INFO_DATA_SZ 256
+#define MBOX_TX_NAME "tx"
+#define MBOX_RX_NAME "rx"
+
+#define SE_TYPE_STR_DBG "dbg"
+#define SE_TYPE_STR_HSM "hsm"
+
+#define SE_TYPE_ID_DBG 0x1
+#define SE_TYPE_ID_HSM 0x2
+
+struct se_fw_img_name {
+ const u8 *prim_fw_nm_in_rfs;
+ const u8 *seco_fw_nm_in_rfs;
+};
+
+struct se_fw_load_info {
+ const struct se_fw_img_name *se_fw_img_nm;
+ bool is_fw_tobe_loaded;
+ bool imem_mgmt;
+ struct se_imem_buf imem;
+};
+
+struct se_var_info {
+ u16 soc_rev;
+ struct se_fw_load_info load_fw;
+};
+
+/* contains fixed information */
+struct se_soc_info {
+ const u16 soc_id;
+ const bool soc_register;
+ const struct se_fw_img_name se_fw_img_nm;
+};
+
+struct se_if_node {
+ struct se_soc_info *se_info;
+ u8 *pool_name;
+ bool reserved_dma_ranges;
+ struct se_if_defines if_defs;
+};
+
+/* common for all the SoC. */
+static struct se_var_info var_se_info;
+
+static struct se_soc_info se_imx8ulp_info = {
+ .soc_id = SOC_ID_OF_IMX8ULP,
+ .soc_register = true,
+ .se_fw_img_nm = {
+ .prim_fw_nm_in_rfs = IMX_ELE_FW_DIR
+ "mx8ulpa2-ahab-container.img",
+ .seco_fw_nm_in_rfs = IMX_ELE_FW_DIR
+ "mx8ulpa2ext-ahab-container.img",
+ },
+};
+
+static struct se_if_node imx8ulp_se_ele_hsm = {
+ .se_info = &se_imx8ulp_info,
+ .pool_name = "sram",
+ .reserved_dma_ranges = true,
+ .if_defs = {
+ .se_if_type = SE_TYPE_ID_HSM,
+ .cmd_tag = 0x17,
+ .rsp_tag = 0xe1,
+ .success_tag = ELE_SUCCESS_IND,
+ .base_api_ver = MESSAGING_VERSION_6,
+ .fw_api_ver = MESSAGING_VERSION_7,
+ },
+};
+
+static struct se_soc_info se_imx93_info = {
+ .soc_id = SOC_ID_OF_IMX93,
+};
+
+static struct se_if_node imx93_se_ele_hsm = {
+ .se_info = &se_imx93_info,
+ .reserved_dma_ranges = true,
+ .if_defs = {
+ .se_if_type = SE_TYPE_ID_HSM,
+ .cmd_tag = 0x17,
+ .rsp_tag = 0xe1,
+ .success_tag = ELE_SUCCESS_IND,
+ .base_api_ver = MESSAGING_VERSION_6,
+ .fw_api_ver = MESSAGING_VERSION_7,
+ },
+};
+
+static const struct of_device_id se_match[] = {
+ { .compatible = "fsl,imx8ulp-se-ele-hsm", .data = &imx8ulp_se_ele_hsm},
+ { .compatible = "fsl,imx93-se-ele-hsm", .data = &imx93_se_ele_hsm},
+ {},
+};
+
+char *get_se_if_name(u8 se_if_id)
+{
+ switch (se_if_id) {
+ case SE_TYPE_ID_DBG: return SE_TYPE_STR_DBG;
+ case SE_TYPE_ID_HSM: return SE_TYPE_STR_HSM;
+ }
+
+ return NULL;
+}
+
+static struct se_fw_load_info *get_load_fw_instance(struct se_if_priv *priv)
+{
+ return &var_se_info.load_fw;
+}
+
+static int get_se_soc_info(struct se_if_priv *priv, const struct se_soc_info *se_info)
+{
+ struct se_fw_load_info *load_fw = get_load_fw_instance(priv);
+ struct soc_device_attribute *attr;
+ u8 data[MAX_SOC_INFO_DATA_SZ];
+ struct ele_dev_info *s_info;
+ struct soc_device *sdev;
+ int err = 0;
+
+ /*
+ * This function should be called once.
+ * Check if the se_soc_rev is zero to continue.
+ */
+ if (var_se_info.soc_rev)
+ return err;
+
+ err = ele_fetch_soc_info(priv, &data);
+ if (err < 0)
+ return dev_err_probe(priv->dev, err, "Failed to fetch SoC Info.");
+ s_info = (void *)data;
+ var_se_info.soc_rev = s_info->d_info.soc_rev;
+ load_fw->imem.state = s_info->d_addn_info.imem_state;
+
+ if (!se_info->soc_register)
+ return 0;
+
+ attr = devm_kzalloc(priv->dev, sizeof(*attr), GFP_KERNEL);
+ if (!attr)
+ return -ENOMEM;
+
+ if (FIELD_GET(DEV_GETINFO_MIN_VER_MASK, var_se_info.soc_rev))
+ attr->revision = devm_kasprintf(priv->dev, GFP_KERNEL, "%x.%x",
+ FIELD_GET(DEV_GETINFO_MIN_VER_MASK,
+ var_se_info.soc_rev),
+ FIELD_GET(DEV_GETINFO_MAJ_VER_MASK,
+ var_se_info.soc_rev));
+ else
+ attr->revision = devm_kasprintf(priv->dev, GFP_KERNEL, "%x",
+ FIELD_GET(DEV_GETINFO_MAJ_VER_MASK,
+ var_se_info.soc_rev));
+
+ switch (se_info->soc_id) {
+ case SOC_ID_OF_IMX8ULP:
+ attr->soc_id = "i.MX8ULP";
+ break;
+ case SOC_ID_OF_IMX93:
+ attr->soc_id = "i.MX93";
+ break;
+ }
+
+ err = of_property_read_string(of_root, "model", &attr->machine);
+ if (err)
+ return -EINVAL;
+
+ attr->family = "Freescale i.MX";
+
+ attr->serial_number = devm_kasprintf(priv->dev,
+ GFP_KERNEL, "%016llX",
+ GET_SERIAL_NUM_FROM_UID(s_info->d_info.uid,
+ MAX_UID_SIZE >> 2));
+
+ sdev = soc_device_register(attr);
+ if (IS_ERR(sdev))
+ return PTR_ERR(sdev);
+
+ return 0;
+}
+
+/* interface for managed res to free a mailbox channel */
+static void if_mbox_free_channel(void *mbox_chan)
+{
+ mbox_free_channel(mbox_chan);
+}
+
+static int se_if_request_channel(struct device *dev, struct mbox_chan **chan,
+ struct mbox_client *cl, const char *name)
+{
+ struct mbox_chan *t_chan;
+ int ret = 0;
+
+ t_chan = mbox_request_channel_byname(cl, name);
+ if (IS_ERR(t_chan))
+ return dev_err_probe(dev, PTR_ERR(t_chan),
+ "Failed to request %s channel.", name);
+
+ ret = devm_add_action_or_reset(dev, if_mbox_free_channel, t_chan);
+ if (ret)
+ return dev_err_probe(dev, -EPERM,
+ "Failed to add-action for removal of mbox: %s\n",
+ name);
+ *chan = t_chan;
+
+ return ret;
+}
+
+static void se_if_probe_cleanup(void *plat_dev)
+{
+ struct platform_device *pdev = plat_dev;
+ struct se_fw_load_info *load_fw;
+ struct device *dev = &pdev->dev;
+ struct se_if_priv *priv;
+
+ priv = dev_get_drvdata(dev);
+ load_fw = get_load_fw_instance(priv);
+
+ /*
+ * In se_if_request_channel(), passed the clean-up functional
+ * pointer reference as action to devm_add_action_or_reset().
+ * No need to free the mbox channels here.
+ */
+
+ /*
+ * free the buffer in se remove, previously allocated
+ * in se probe to store encrypted IMEM
+ */
+ if (load_fw && load_fw->imem.buf) {
+ dmam_free_coherent(dev, ELE_IMEM_SIZE, load_fw->imem.buf,
+ load_fw->imem.phyaddr);
+ load_fw->imem.buf = NULL;
+ }
+
+ /*
+ * No need to check, if reserved memory is allocated
+ * before calling for its release. Or clearing the
+ * un-set bit.
+ */
+ of_reserved_mem_device_release(dev);
+}
+
+static int se_if_probe(struct platform_device *pdev)
+{
+ const struct se_soc_info *se_info;
+ const struct se_if_node *if_node;
+ struct se_fw_load_info *load_fw;
+ struct device *dev = &pdev->dev;
+ struct se_if_priv *priv;
+ int ret;
+
+ if_node = device_get_match_data(dev);
+ if (!if_node)
+ return -EINVAL;
+
+ se_info = if_node->se_info;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ priv->if_defs = &if_node->if_defs;
+ dev_set_drvdata(dev, priv);
+
+ ret = devm_add_action_or_reset(dev, se_if_probe_cleanup, pdev);
+ if (ret)
+ return ret;
+
+ /* Mailbox client configuration */
+ priv->se_mb_cl.dev = dev;
+ priv->se_mb_cl.tx_block = false;
+ priv->se_mb_cl.knows_txdone = true;
+ priv->se_mb_cl.rx_callback = se_if_rx_callback;
+
+ ret = se_if_request_channel(dev, &priv->tx_chan, &priv->se_mb_cl, MBOX_TX_NAME);
+ if (ret)
+ return ret;
+
+ ret = se_if_request_channel(dev, &priv->rx_chan, &priv->se_mb_cl, MBOX_RX_NAME);
+ if (ret)
+ return ret;
+
+ mutex_init(&priv->se_if_cmd_lock);
+
+ init_completion(&priv->waiting_rsp_clbk_hdl.done);
+ init_completion(&priv->cmd_receiver_clbk_hdl.done);
+
+ if (if_node->pool_name) {
+ priv->mem_pool = of_gen_pool_get(dev->of_node, if_node->pool_name, 0);
+ if (!priv->mem_pool)
+ return dev_err_probe(dev, -ENOMEM,
+ "Unable to get sram pool = %s.",
+ if_node->pool_name);
+ }
+
+ if (if_node->reserved_dma_ranges) {
+ ret = of_reserved_mem_device_init(dev);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to init reserved memory region.");
+ }
+
+ if (if_node->if_defs.se_if_type == SE_TYPE_ID_HSM) {
+ ret = get_se_soc_info(priv, se_info);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to fetch SoC Info.");
+ }
+
+ /* By default, there is no pending FW to be loaded.*/
+ if (se_info->se_fw_img_nm.seco_fw_nm_in_rfs) {
+ load_fw = get_load_fw_instance(priv);
+ load_fw->se_fw_img_nm = &se_info->se_fw_img_nm;
+ load_fw->is_fw_tobe_loaded = true;
+
+ if (load_fw->se_fw_img_nm->prim_fw_nm_in_rfs) {
+ /* allocate buffer where SE store encrypted IMEM */
+ load_fw->imem.buf = dmam_alloc_coherent(priv->dev, ELE_IMEM_SIZE,
+ &load_fw->imem.phyaddr,
+ GFP_KERNEL);
+ if (!load_fw->imem.buf)
+ return dev_err_probe(dev, -ENOMEM,
+ "dmam-alloc-failed: To store encr-IMEM.");
+ load_fw->imem_mgmt = true;
+ }
+ }
+ dev_info(dev, "i.MX secure-enclave: %s0 interface to firmware, configured.",
+ get_se_if_name(priv->if_defs->se_if_type));
+
+ return ret;
+}
+
+static int se_suspend(struct device *dev)
+{
+ struct se_if_priv *priv = dev_get_drvdata(dev);
+ struct se_fw_load_info *load_fw;
+ int ret = 0;
+
+ load_fw = get_load_fw_instance(priv);
+
+ if (load_fw->imem_mgmt)
+ ret = se_save_imem_state(priv, &load_fw->imem);
+
+ return ret;
+}
+
+static int se_resume(struct device *dev)
+{
+ struct se_if_priv *priv = dev_get_drvdata(dev);
+ struct se_fw_load_info *load_fw;
+
+ load_fw = get_load_fw_instance(priv);
+
+ if (load_fw->imem_mgmt)
+ se_restore_imem_state(priv, &load_fw->imem);
+
+ return 0;
+}
+
+static const struct dev_pm_ops se_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(se_suspend, se_resume)
+};
+
+static struct platform_driver se_driver = {
+ .driver = {
+ .name = "fsl-se",
+ .of_match_table = se_match,
+ .pm = &se_pm,
+ },
+ .probe = se_if_probe,
+};
+MODULE_DEVICE_TABLE(of, se_match);
+
+module_platform_driver(se_driver);
+MODULE_AUTHOR("Pankaj Gupta <pankaj.gupta@nxp.com>");
+MODULE_DESCRIPTION("iMX Secure Enclave Driver.");
+MODULE_LICENSE("GPL");
diff --git a/drivers/firmware/imx/se_ctrl.h b/drivers/firmware/imx/se_ctrl.h
new file mode 100644
index 000000000000..b15c4022a46c
--- /dev/null
+++ b/drivers/firmware/imx/se_ctrl.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2025 NXP
+ */
+
+#ifndef SE_MU_H
+#define SE_MU_H
+
+#include <linux/miscdevice.h>
+#include <linux/semaphore.h>
+#include <linux/mailbox_client.h>
+
+#define MAX_FW_LOAD_RETRIES 50
+#define SE_MSG_WORD_SZ 0x4
+
+#define RES_STATUS(x) FIELD_GET(0x000000ff, x)
+#define MAX_NVM_MSG_LEN (256)
+#define MESSAGING_VERSION_6 0x6
+#define MESSAGING_VERSION_7 0x7
+
+struct se_clbk_handle {
+ struct completion done;
+ bool signal_rcvd;
+ u32 rx_msg_sz;
+ /*
+ * Assignment of the rx_msg buffer to held till the
+ * received content as part callback function, is copied.
+ */
+ struct se_api_msg *rx_msg;
+};
+
+struct se_imem_buf {
+ u8 *buf;
+ phys_addr_t phyaddr;
+ u32 size;
+ u32 state;
+};
+
+/* Header of the messages exchange with the EdgeLock Enclave */
+struct se_msg_hdr {
+ u8 ver;
+ u8 size;
+ u8 command;
+ u8 tag;
+} __packed;
+
+#define SE_MU_HDR_SZ 4
+
+struct se_api_msg {
+ struct se_msg_hdr header;
+ u32 data[];
+};
+
+struct se_if_defines {
+ const u8 se_if_type;
+ u8 cmd_tag;
+ u8 rsp_tag;
+ u8 success_tag;
+ u8 base_api_ver;
+ u8 fw_api_ver;
+};
+
+struct se_if_priv {
+ struct device *dev;
+
+ struct se_clbk_handle cmd_receiver_clbk_hdl;
+ /*
+ * Update to the waiting_rsp_dev, to be protected
+ * under se_if_cmd_lock.
+ */
+ struct se_clbk_handle waiting_rsp_clbk_hdl;
+ /*
+ * prevent new command to be sent on the se interface while previous
+ * command is still processing. (response is awaited)
+ */
+ struct mutex se_if_cmd_lock;
+
+ struct mbox_client se_mb_cl;
+ struct mbox_chan *tx_chan, *rx_chan;
+
+ struct gen_pool *mem_pool;
+ const struct se_if_defines *if_defs;
+};
+
+char *get_se_if_name(u8 se_if_id);
+#endif
diff --git a/include/linux/firmware/imx/se_api.h b/include/linux/firmware/imx/se_api.h
new file mode 100644
index 000000000000..b1c4c9115d7b
--- /dev/null
+++ b/include/linux/firmware/imx/se_api.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2025 NXP
+ */
+
+#ifndef __SE_API_H__
+#define __SE_API_H__
+
+#include <linux/types.h>
+
+#define SOC_ID_OF_IMX8ULP 0x084d
+#define SOC_ID_OF_IMX93 0x9300
+
+#endif /* __SE_API_H__ */
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v19 4/7] firmware: imx: device context dedicated to priv
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
` (2 preceding siblings ...)
2025-09-26 21:09 ` [PATCH v19 3/7] firmware: imx: add driver for NXP EdgeLock Enclave Pankaj Gupta
@ 2025-09-26 21:09 ` Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 5/7] firmware: drivers: imx: adds miscdev Pankaj Gupta
` (4 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-09-26 21:09 UTC (permalink / raw)
To: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel,
Frank Li
Add priv_dev_ctx to prepare enabling misc-device context based send-receive
path, to communicate with FW.
No functionality change.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/firmware/imx/ele_base_msg.c | 14 +++++-----
drivers/firmware/imx/ele_common.c | 51 +++++++++++++++++++++----------------
drivers/firmware/imx/ele_common.h | 8 +++---
drivers/firmware/imx/se_ctrl.c | 29 +++++++++++++++++++++
drivers/firmware/imx/se_ctrl.h | 9 +++++++
5 files changed, 78 insertions(+), 33 deletions(-)
diff --git a/drivers/firmware/imx/ele_base_msg.c b/drivers/firmware/imx/ele_base_msg.c
index a070acbd895c..b233729dd13d 100644
--- a/drivers/firmware/imx/ele_base_msg.c
+++ b/drivers/firmware/imx/ele_base_msg.c
@@ -59,8 +59,8 @@ int ele_get_info(struct se_if_priv *priv, struct ele_dev_info *s_info)
tx_msg->data[0] = upper_32_bits(get_info_addr);
tx_msg->data[1] = lower_32_bits(get_info_addr);
tx_msg->data[2] = sizeof(*s_info);
- ret = ele_msg_send_rcv(priv, tx_msg, ELE_GET_INFO_REQ_MSG_SZ, rx_msg,
- ELE_GET_INFO_RSP_MSG_SZ);
+ ret = ele_msg_send_rcv(priv->priv_dev_ctx, tx_msg, ELE_GET_INFO_REQ_MSG_SZ,
+ rx_msg, ELE_GET_INFO_RSP_MSG_SZ);
if (ret < 0)
goto exit;
@@ -109,8 +109,8 @@ int ele_ping(struct se_if_priv *priv)
return ret;
}
- ret = ele_msg_send_rcv(priv, tx_msg, ELE_PING_REQ_SZ, rx_msg,
- ELE_PING_RSP_SZ);
+ ret = ele_msg_send_rcv(priv->priv_dev_ctx, tx_msg, ELE_PING_REQ_SZ,
+ rx_msg, ELE_PING_RSP_SZ);
if (ret < 0)
return ret;
@@ -154,7 +154,7 @@ int ele_service_swap(struct se_if_priv *priv,
if (!tx_msg->data[4])
return -EINVAL;
- ret = ele_msg_send_rcv(priv, tx_msg, ELE_SERVICE_SWAP_REQ_MSG_SZ,
+ ret = ele_msg_send_rcv(priv->priv_dev_ctx, tx_msg, ELE_SERVICE_SWAP_REQ_MSG_SZ,
rx_msg, ELE_SERVICE_SWAP_RSP_MSG_SZ);
if (ret < 0)
return ret;
@@ -199,7 +199,7 @@ int ele_fw_authenticate(struct se_if_priv *priv, phys_addr_t contnr_addr,
tx_msg->data[1] = upper_32_bits(contnr_addr);
tx_msg->data[2] = img_addr;
- ret = ele_msg_send_rcv(priv, tx_msg, ELE_FW_AUTH_REQ_SZ, rx_msg,
+ ret = ele_msg_send_rcv(priv->priv_dev_ctx, tx_msg, ELE_FW_AUTH_REQ_SZ, rx_msg,
ELE_FW_AUTH_RSP_MSG_SZ);
if (ret < 0)
return ret;
@@ -238,7 +238,7 @@ int ele_debug_dump(struct se_if_priv *priv)
do {
memset(rx_msg, 0x0, ELE_DEBUG_DUMP_RSP_SZ);
- ret = ele_msg_send_rcv(priv, tx_msg, ELE_DEBUG_DUMP_REQ_SZ,
+ ret = ele_msg_send_rcv(priv->priv_dev_ctx, tx_msg, ELE_DEBUG_DUMP_REQ_SZ,
rx_msg, ELE_DEBUG_DUMP_RSP_SZ);
if (ret < 0)
return ret;
diff --git a/drivers/firmware/imx/ele_common.c b/drivers/firmware/imx/ele_common.c
index 748eb09474d7..f26fb4d55a9a 100644
--- a/drivers/firmware/imx/ele_common.c
+++ b/drivers/firmware/imx/ele_common.c
@@ -42,7 +42,7 @@ u32 se_get_msg_chksum(u32 *msg, u32 msg_len)
return chksum;
}
-int ele_msg_rcv(struct se_if_priv *priv, struct se_clbk_handle *se_clbk_hdl)
+int ele_msg_rcv(struct se_if_device_ctx *dev_ctx, struct se_clbk_handle *se_clbk_hdl)
{
unsigned long timeout;
int ret;
@@ -52,8 +52,8 @@ int ele_msg_rcv(struct se_if_priv *priv, struct se_clbk_handle *se_clbk_hdl)
ret = wait_for_completion_interruptible_timeout(&se_clbk_hdl->done, timeout);
if (ret == -ERESTARTSYS) {
- if (priv->waiting_rsp_clbk_hdl.rx_msg) {
- priv->waiting_rsp_clbk_hdl.signal_rcvd = true;
+ if (dev_ctx->priv->waiting_rsp_clbk_hdl.dev_ctx) {
+ dev_ctx->priv->waiting_rsp_clbk_hdl.signal_rcvd = true;
continue;
}
ret = -EINTR;
@@ -66,7 +66,7 @@ int ele_msg_rcv(struct se_if_priv *priv, struct se_clbk_handle *se_clbk_hdl)
return ret;
}
-int ele_msg_send(struct se_if_priv *priv,
+int ele_msg_send(struct se_if_device_ctx *dev_ctx,
void *tx_msg,
int tx_msg_sz)
{
@@ -78,15 +78,16 @@ int ele_msg_send(struct se_if_priv *priv,
* carried in the message.
*/
if (header->size << 2 != tx_msg_sz) {
- dev_err(priv->dev,
- "User buf hdr: 0x%x, sz mismatced with input-sz (%d != %d).",
- *(u32 *)header, header->size << 2, tx_msg_sz);
+ dev_err(dev_ctx->priv->dev,
+ "%s: User buf hdr: 0x%x, sz mismatced with input-sz (%d != %d).",
+ dev_ctx->devname, *(u32 *)header, header->size << 2, tx_msg_sz);
return -EINVAL;
}
- err = mbox_send_message(priv->tx_chan, tx_msg);
+ err = mbox_send_message(dev_ctx->priv->tx_chan, tx_msg);
if (err < 0) {
- dev_err(priv->dev, "Error: mbox_send_message failure.\n");
+ dev_err(dev_ctx->priv->dev,
+ "%s: Error: mbox_send_message failure.", dev_ctx->devname);
return err;
}
@@ -94,27 +95,31 @@ int ele_msg_send(struct se_if_priv *priv,
}
/* API used for send/receive blocking call. */
-int ele_msg_send_rcv(struct se_if_priv *priv, void *tx_msg, int tx_msg_sz,
- void *rx_msg, int exp_rx_msg_sz)
+int ele_msg_send_rcv(struct se_if_device_ctx *dev_ctx, void *tx_msg,
+ int tx_msg_sz, void *rx_msg, int exp_rx_msg_sz)
{
+ struct se_if_priv *priv = dev_ctx->priv;
int err;
guard(mutex)(&priv->se_if_cmd_lock);
+ priv->waiting_rsp_clbk_hdl.dev_ctx = dev_ctx;
priv->waiting_rsp_clbk_hdl.rx_msg_sz = exp_rx_msg_sz;
priv->waiting_rsp_clbk_hdl.rx_msg = rx_msg;
- err = ele_msg_send(priv, tx_msg, tx_msg_sz);
+ err = ele_msg_send(dev_ctx, tx_msg, tx_msg_sz);
if (err < 0)
return err;
- err = ele_msg_rcv(priv, &priv->waiting_rsp_clbk_hdl);
+ err = ele_msg_rcv(dev_ctx, &priv->waiting_rsp_clbk_hdl);
if (priv->waiting_rsp_clbk_hdl.signal_rcvd) {
err = -EINTR;
priv->waiting_rsp_clbk_hdl.signal_rcvd = false;
- dev_err(priv->dev, "Err[0x%x]:Interrupted by signal.\n", err);
+ dev_err(priv->dev, "%s: Err[0x%x]:Interrupted by signal.",
+ dev_ctx->devname, err);
}
+ priv->waiting_rsp_clbk_hdl.dev_ctx = NULL;
return err;
}
@@ -159,8 +164,8 @@ void se_if_rx_callback(struct mbox_client *mbox_cl, void *msg)
/* Incoming command: wake up the receiver if any. */
if (header->tag == priv->if_defs->cmd_tag) {
se_clbk_hdl = &priv->cmd_receiver_clbk_hdl;
- dev_dbg(dev, "Selecting cmd receiver for mesg header:0x%x.",
- *(u32 *)header);
+ dev_dbg(dev, "Selecting cmd receiver:%s for mesg header:0x%x.",
+ se_clbk_hdl->dev_ctx->devname, *(u32 *)header);
/*
* Pre-allocated buffer of MAX_NVM_MSG_LEN
@@ -169,8 +174,9 @@ void se_if_rx_callback(struct mbox_client *mbox_cl, void *msg)
*/
if (rx_msg_sz > MAX_NVM_MSG_LEN) {
dev_err(dev,
- "CMD-RCVER NVM: hdr(0x%x) with different sz(%d != %d).\n",
- *(u32 *)header, rx_msg_sz, se_clbk_hdl->rx_msg_sz);
+ "%s: CMD-RCVER NVM: hdr(0x%x) with different sz(%d != %d).\n",
+ se_clbk_hdl->dev_ctx->devname, *(u32 *)header,
+ rx_msg_sz, se_clbk_hdl->rx_msg_sz);
se_clbk_hdl->rx_msg_sz = MAX_NVM_MSG_LEN;
}
@@ -178,14 +184,15 @@ void se_if_rx_callback(struct mbox_client *mbox_cl, void *msg)
} else if (header->tag == priv->if_defs->rsp_tag) {
se_clbk_hdl = &priv->waiting_rsp_clbk_hdl;
- dev_dbg(dev, "Selecting resp waiter for mesg header:0x%x.",
- *(u32 *)header);
+ dev_dbg(dev, "Selecting resp waiter:%s for mesg header:0x%x.",
+ se_clbk_hdl->dev_ctx->devname, *(u32 *)header);
if (rx_msg_sz != se_clbk_hdl->rx_msg_sz &&
check_hdr_exception_for_sz(priv, header)) {
dev_err(dev,
- "Rsp to CMD: hdr(0x%x) with different sz(%d != %d).\n",
- *(u32 *)header, rx_msg_sz, se_clbk_hdl->rx_msg_sz);
+ "%s: Rsp to CMD: hdr(0x%x) with different sz(%d != %d).\n",
+ se_clbk_hdl->dev_ctx->devname, *(u32 *)header,
+ rx_msg_sz, se_clbk_hdl->rx_msg_sz);
se_clbk_hdl->rx_msg_sz = min(rx_msg_sz, se_clbk_hdl->rx_msg_sz);
}
diff --git a/drivers/firmware/imx/ele_common.h b/drivers/firmware/imx/ele_common.h
index 96e987ef6f88..5bac14439d7d 100644
--- a/drivers/firmware/imx/ele_common.h
+++ b/drivers/firmware/imx/ele_common.h
@@ -14,12 +14,12 @@
u32 se_get_msg_chksum(u32 *msg, u32 msg_len);
-int ele_msg_rcv(struct se_if_priv *priv, struct se_clbk_handle *se_clbk_hdl);
+int ele_msg_rcv(struct se_if_device_ctx *dev_ctx, struct se_clbk_handle *se_clbk_hdl);
-int ele_msg_send(struct se_if_priv *priv, void *tx_msg, int tx_msg_sz);
+int ele_msg_send(struct se_if_device_ctx *dev_ctx, void *tx_msg, int tx_msg_sz);
-int ele_msg_send_rcv(struct se_if_priv *priv, void *tx_msg, int tx_msg_sz,
- void *rx_msg, int exp_rx_msg_sz);
+int ele_msg_send_rcv(struct se_if_device_ctx *dev_ctx, void *tx_msg,
+ int tx_msg_sz, void *rx_msg, int exp_rx_msg_sz);
void se_if_rx_callback(struct mbox_client *mbox_cl, void *msg);
diff --git a/drivers/firmware/imx/se_ctrl.c b/drivers/firmware/imx/se_ctrl.c
index 5f978c97da4a..40544cbc70ca 100644
--- a/drivers/firmware/imx/se_ctrl.c
+++ b/drivers/firmware/imx/se_ctrl.c
@@ -203,6 +203,29 @@ static int get_se_soc_info(struct se_if_priv *priv, const struct se_soc_info *se
return 0;
}
+static int init_misc_device_context(struct se_if_priv *priv, int ch_id,
+ struct se_if_device_ctx **new_dev_ctx)
+{
+ struct se_if_device_ctx *dev_ctx;
+ int ret = 0;
+
+ dev_ctx = devm_kzalloc(priv->dev, sizeof(*dev_ctx), GFP_KERNEL);
+
+ if (!dev_ctx)
+ return -ENOMEM;
+
+ dev_ctx->devname = devm_kasprintf(priv->dev, GFP_KERNEL, "%s0_ch%d",
+ get_se_if_name(priv->if_defs->se_if_type),
+ ch_id);
+ if (!dev_ctx->devname)
+ return -ENOMEM;
+
+ dev_ctx->priv = priv;
+ *new_dev_ctx = dev_ctx;
+
+ return ret;
+}
+
/* interface for managed res to free a mailbox channel */
static void if_mbox_free_channel(void *mbox_chan)
{
@@ -325,6 +348,12 @@ static int se_if_probe(struct platform_device *pdev)
"Failed to init reserved memory region.");
}
+ ret = init_misc_device_context(priv, 0, &priv->priv_dev_ctx);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed[0x%x] to create device contexts.",
+ ret);
+
if (if_node->if_defs.se_if_type == SE_TYPE_ID_HSM) {
ret = get_se_soc_info(priv, se_info);
if (ret)
diff --git a/drivers/firmware/imx/se_ctrl.h b/drivers/firmware/imx/se_ctrl.h
index b15c4022a46c..b5e7705e2f26 100644
--- a/drivers/firmware/imx/se_ctrl.h
+++ b/drivers/firmware/imx/se_ctrl.h
@@ -19,6 +19,7 @@
#define MESSAGING_VERSION_7 0x7
struct se_clbk_handle {
+ struct se_if_device_ctx *dev_ctx;
struct completion done;
bool signal_rcvd;
u32 rx_msg_sz;
@@ -36,6 +37,12 @@ struct se_imem_buf {
u32 state;
};
+/* Private struct for each char device instance. */
+struct se_if_device_ctx {
+ struct se_if_priv *priv;
+ const char *devname;
+};
+
/* Header of the messages exchange with the EdgeLock Enclave */
struct se_msg_hdr {
u8 ver;
@@ -80,6 +87,8 @@ struct se_if_priv {
struct gen_pool *mem_pool;
const struct se_if_defines *if_defs;
+
+ struct se_if_device_ctx *priv_dev_ctx;
};
char *get_se_if_name(u8 se_if_id);
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v19 5/7] firmware: drivers: imx: adds miscdev
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
` (3 preceding siblings ...)
2025-09-26 21:09 ` [PATCH v19 4/7] firmware: imx: device context dedicated to priv Pankaj Gupta
@ 2025-09-26 21:09 ` Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 6/7] arm64: dts: imx8ulp: add secure enclave node Pankaj Gupta
` (3 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-09-26 21:09 UTC (permalink / raw)
To: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel,
Frank Li
Adds the driver for communication interface to secure-enclave, for
exchanging messages with NXP secure enclave HW IP(s) like EdgeLock Enclave
from:
- User-Space Applications via character driver.
ABI documentation for the NXP secure-enclave driver.
User-space library using this driver:
- i.MX Secure Enclave library:
-- URL: https://github.com/nxp-imx/imx-secure-enclave.git,
- i.MX Secure Middle-Ware:
-- URL: https://github.com/nxp-imx/imx-smw.git
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
changes from v17 to v18
- Collected Frank's R-b tag.
---
Documentation/ABI/testing/se-cdev | 43 +++
drivers/firmware/imx/ele_common.c | 20 +-
drivers/firmware/imx/ele_common.h | 4 +
drivers/firmware/imx/se_ctrl.c | 733 +++++++++++++++++++++++++++++++++++++-
drivers/firmware/imx/se_ctrl.h | 33 ++
include/uapi/linux/se_ioctl.h | 97 +++++
6 files changed, 918 insertions(+), 12 deletions(-)
diff --git a/Documentation/ABI/testing/se-cdev b/Documentation/ABI/testing/se-cdev
new file mode 100644
index 000000000000..dad39ffd245a
--- /dev/null
+++ b/Documentation/ABI/testing/se-cdev
@@ -0,0 +1,43 @@
+What: /dev/<se>_mu[0-9]+_ch[0-9]+
+Date: Mar 2025
+KernelVersion: 6.8
+Contact: linux-imx@nxp.com, pankaj.gupta@nxp.com
+Description:
+ NXP offers multiple hardware IP(s) for secure enclaves like EdgeLock-
+ Enclave(ELE), SECO. The character device file descriptors
+ /dev/<se>_mu*_ch* are the interface between userspace NXP's secure-
+ enclave shared library and the kernel driver.
+
+ The ioctl(2)-based ABI is defined and documented in
+ [include]<linux/firmware/imx/ele_mu_ioctl.h>.
+ ioctl(s) are used primarily for:
+ - shared memory management
+ - allocation of I/O buffers
+ - getting mu info
+ - setting a dev-ctx as receiver to receive all the commands from FW
+ - getting SoC info
+ - send command and receive command response
+
+ The following file operations are supported:
+
+ open(2)
+ Currently the only useful flags are O_RDWR.
+
+ read(2)
+ Every read() from the opened character device context is waiting on
+ wait_event_interruptible, that gets set by the registered mailbox callback
+ function, indicating a message received from the firmware on message-
+ unit.
+
+ write(2)
+ Every write() to the opened character device context needs to acquire
+ mailbox_lock before sending message on to the message unit.
+
+ close(2)
+ Stops and frees up the I/O contexts that were associated
+ with the file descriptor.
+
+Users: https://github.com/nxp-imx/imx-secure-enclave.git,
+ https://github.com/nxp-imx/imx-smw.git
+ crypto/skcipher,
+ drivers/nvmem/imx-ocotp-ele.c
diff --git a/drivers/firmware/imx/ele_common.c b/drivers/firmware/imx/ele_common.c
index f26fb4d55a9a..dc4607984f00 100644
--- a/drivers/firmware/imx/ele_common.c
+++ b/drivers/firmware/imx/ele_common.c
@@ -42,15 +42,22 @@ u32 se_get_msg_chksum(u32 *msg, u32 msg_len)
return chksum;
}
+void set_se_rcv_msg_timeout(struct se_if_priv *priv, u32 timeout_ms)
+{
+ priv->se_rcv_msg_timeout_ms = timeout_ms;
+}
+
int ele_msg_rcv(struct se_if_device_ctx *dev_ctx, struct se_clbk_handle *se_clbk_hdl)
{
- unsigned long timeout;
+ unsigned long timeout_ms;
int ret;
do {
- timeout = MAX_SCHEDULE_TIMEOUT;
+ timeout_ms = MAX_SCHEDULE_TIMEOUT;
+ if (dev_ctx->priv->cmd_receiver_clbk_hdl.dev_ctx != dev_ctx)
+ timeout_ms = msecs_to_jiffies(dev_ctx->priv->se_rcv_msg_timeout_ms);
- ret = wait_for_completion_interruptible_timeout(&se_clbk_hdl->done, timeout);
+ ret = wait_for_completion_interruptible_timeout(&se_clbk_hdl->done, timeout_ms);
if (ret == -ERESTARTSYS) {
if (dev_ctx->priv->waiting_rsp_clbk_hdl.dev_ctx) {
dev_ctx->priv->waiting_rsp_clbk_hdl.signal_rcvd = true;
@@ -59,6 +66,13 @@ int ele_msg_rcv(struct se_if_device_ctx *dev_ctx, struct se_clbk_handle *se_clbk
ret = -EINTR;
break;
}
+ if (ret == 0) {
+ ret = -ETIMEDOUT;
+ dev_err(dev_ctx->priv->dev,
+ "Fatal Error: SE interface: %s0, hangs indefinitely.\n",
+ get_se_if_name(dev_ctx->priv->if_defs->se_if_type));
+ break;
+ }
ret = se_clbk_hdl->rx_msg_sz;
break;
} while (ret < 0);
diff --git a/drivers/firmware/imx/ele_common.h b/drivers/firmware/imx/ele_common.h
index 5bac14439d7d..3e88ea45ca5d 100644
--- a/drivers/firmware/imx/ele_common.h
+++ b/drivers/firmware/imx/ele_common.h
@@ -12,6 +12,10 @@
#define IMX_ELE_FW_DIR "imx/ele/"
+#define SE_RCV_MSG_DEFAULT_TIMEOUT 5000
+#define SE_RCV_MSG_LONG_TIMEOUT 5000000
+
+void set_se_rcv_msg_timeout(struct se_if_priv *priv, u32 val);
u32 se_get_msg_chksum(u32 *msg, u32 msg_len);
int ele_msg_rcv(struct se_if_device_ctx *dev_ctx, struct se_clbk_handle *se_clbk_hdl);
diff --git a/drivers/firmware/imx/se_ctrl.c b/drivers/firmware/imx/se_ctrl.c
index 40544cbc70ca..5766d0759955 100644
--- a/drivers/firmware/imx/se_ctrl.c
+++ b/drivers/firmware/imx/se_ctrl.c
@@ -23,6 +23,7 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/sys_soc.h>
+#include <uapi/linux/se_ioctl.h>
#include "ele_base_msg.h"
#include "ele_common.h"
@@ -32,12 +33,6 @@
#define MBOX_TX_NAME "tx"
#define MBOX_RX_NAME "rx"
-#define SE_TYPE_STR_DBG "dbg"
-#define SE_TYPE_STR_HSM "hsm"
-
-#define SE_TYPE_ID_DBG 0x1
-#define SE_TYPE_ID_HSM 0x2
-
struct se_fw_img_name {
const u8 *prim_fw_nm_in_rfs;
const u8 *seco_fw_nm_in_rfs;
@@ -130,6 +125,13 @@ char *get_se_if_name(u8 se_if_id)
return NULL;
}
+static u32 get_se_soc_id(struct se_if_priv *priv)
+{
+ const struct se_soc_info *se_info = device_get_match_data(priv->dev);
+
+ return se_info->soc_id;
+}
+
static struct se_fw_load_info *get_load_fw_instance(struct se_if_priv *priv)
{
return &var_se_info.load_fw;
@@ -203,8 +205,213 @@ static int get_se_soc_info(struct se_if_priv *priv, const struct se_soc_info *se
return 0;
}
+static int load_firmware(struct se_if_priv *priv, const u8 *se_img_file_to_load)
+{
+ const struct firmware *fw = NULL;
+ phys_addr_t se_fw_phyaddr;
+ u8 *se_fw_buf;
+ int ret;
+
+ if (!se_img_file_to_load) {
+ dev_err(priv->dev, "FW image is not provided.");
+ return -EINVAL;
+ }
+ ret = request_firmware(&fw, se_img_file_to_load, priv->dev);
+ if (ret)
+ return ret;
+
+ dev_info(priv->dev, "loading firmware %s.", se_img_file_to_load);
+
+ /* allocate buffer to store the SE FW */
+ se_fw_buf = dma_alloc_coherent(priv->dev, fw->size, &se_fw_phyaddr, GFP_KERNEL);
+ if (!se_fw_buf) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ memcpy(se_fw_buf, fw->data, fw->size);
+ ret = ele_fw_authenticate(priv, se_fw_phyaddr, se_fw_phyaddr);
+ if (ret < 0) {
+ dev_err(priv->dev,
+ "Error %pe: Authenticate & load SE firmware %s.",
+ ERR_PTR(ret), se_img_file_to_load);
+ ret = -EPERM;
+ }
+ dma_free_coherent(priv->dev, fw->size, se_fw_buf, se_fw_phyaddr);
+exit:
+ release_firmware(fw);
+
+ return ret;
+}
+
+static int se_load_firmware(struct se_if_priv *priv)
+{
+ struct se_fw_load_info *load_fw = get_load_fw_instance(priv);
+ int ret = 0;
+
+ if (!load_fw->is_fw_tobe_loaded)
+ return 0;
+
+ if (load_fw->imem.state == ELE_IMEM_STATE_BAD) {
+ ret = load_firmware(priv, load_fw->se_fw_img_nm->prim_fw_nm_in_rfs);
+ if (ret) {
+ dev_err(priv->dev, "Failed to load boot firmware.");
+ return -EPERM;
+ }
+ }
+
+ ret = load_firmware(priv, load_fw->se_fw_img_nm->seco_fw_nm_in_rfs);
+ if (ret) {
+ dev_err(priv->dev, "Failed to load runtime firmware.");
+ return -EPERM;
+ }
+
+ load_fw->is_fw_tobe_loaded = false;
+
+ return ret;
+}
+
+static int init_se_shared_mem(struct se_if_device_ctx *dev_ctx)
+{
+ struct se_shared_mem_mgmt_info *se_shared_mem_mgmt = &dev_ctx->se_shared_mem_mgmt;
+ struct se_if_priv *priv = dev_ctx->priv;
+
+ INIT_LIST_HEAD(&se_shared_mem_mgmt->pending_out);
+ INIT_LIST_HEAD(&se_shared_mem_mgmt->pending_in);
+
+ /*
+ * Allocate some memory for data exchanges with S40x.
+ * This will be used for data not requiring secure memory.
+ */
+ se_shared_mem_mgmt->non_secure_mem.ptr =
+ dma_alloc_coherent(priv->dev, MAX_DATA_SIZE_PER_USER,
+ &se_shared_mem_mgmt->non_secure_mem.dma_addr,
+ GFP_KERNEL);
+ if (!se_shared_mem_mgmt->non_secure_mem.ptr)
+ return -ENOMEM;
+
+ se_shared_mem_mgmt->non_secure_mem.size = MAX_DATA_SIZE_PER_USER;
+ se_shared_mem_mgmt->non_secure_mem.pos = 0;
+
+ return 0;
+}
+
+static void cleanup_se_shared_mem(struct se_if_device_ctx *dev_ctx)
+{
+ struct se_shared_mem_mgmt_info *se_shared_mem_mgmt = &dev_ctx->se_shared_mem_mgmt;
+ struct se_if_priv *priv = dev_ctx->priv;
+
+ /* Free non-secure shared buffer. */
+ dma_free_coherent(priv->dev, MAX_DATA_SIZE_PER_USER,
+ se_shared_mem_mgmt->non_secure_mem.ptr,
+ se_shared_mem_mgmt->non_secure_mem.dma_addr);
+
+ se_shared_mem_mgmt->non_secure_mem.ptr = NULL;
+ se_shared_mem_mgmt->non_secure_mem.dma_addr = 0;
+ se_shared_mem_mgmt->non_secure_mem.size = 0;
+ se_shared_mem_mgmt->non_secure_mem.pos = 0;
+}
+
+/* Need to copy the output data to user-device context.
+ */
+static int se_dev_ctx_cpy_out_data(struct se_if_device_ctx *dev_ctx)
+{
+ struct se_shared_mem_mgmt_info *se_shared_mem_mgmt = &dev_ctx->se_shared_mem_mgmt;
+ struct se_if_priv *priv = dev_ctx->priv;
+ struct se_buf_desc *b_desc, *temp;
+ bool do_cpy = true;
+
+ list_for_each_entry_safe(b_desc, temp, &se_shared_mem_mgmt->pending_out, link) {
+ if (b_desc->usr_buf_ptr && b_desc->shared_buf_ptr && do_cpy) {
+ dev_dbg(priv->dev, "Copying output data to user.");
+ if (do_cpy && copy_to_user(b_desc->usr_buf_ptr,
+ b_desc->shared_buf_ptr,
+ b_desc->size)) {
+ dev_err(priv->dev, "Failure copying output data to user.");
+ do_cpy = false;
+ }
+ }
+
+ if (b_desc->shared_buf_ptr)
+ memset(b_desc->shared_buf_ptr, 0, b_desc->size);
+
+ list_del(&b_desc->link);
+ kfree(b_desc);
+ }
+
+ return do_cpy ? 0 : -EFAULT;
+}
+
+/*
+ * Clean the used Shared Memory space,
+ * whether its Input Data copied from user buffers, or
+ * Data received from FW.
+ */
+static void se_dev_ctx_shared_mem_cleanup(struct se_if_device_ctx *dev_ctx)
+{
+ struct se_shared_mem_mgmt_info *se_shared_mem_mgmt = &dev_ctx->se_shared_mem_mgmt;
+ struct list_head *pending_lists[] = {&se_shared_mem_mgmt->pending_in,
+ &se_shared_mem_mgmt->pending_out};
+ struct se_buf_desc *b_desc, *temp;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pending_lists); i++) {
+ list_for_each_entry_safe(b_desc, temp, pending_lists[i], link) {
+ if (b_desc->shared_buf_ptr)
+ memset(b_desc->shared_buf_ptr, 0, b_desc->size);
+
+ list_del(&b_desc->link);
+ kfree(b_desc);
+ }
+ }
+ se_shared_mem_mgmt->non_secure_mem.pos = 0;
+}
+
+static int add_b_desc_to_pending_list(void *shared_ptr_with_pos,
+ struct se_ioctl_setup_iobuf *io,
+ struct se_if_device_ctx *dev_ctx)
+{
+ struct se_shared_mem_mgmt_info *se_shared_mem_mgmt = &dev_ctx->se_shared_mem_mgmt;
+ struct se_buf_desc *b_desc;
+
+ b_desc = kzalloc(sizeof(*b_desc), GFP_KERNEL);
+ if (!b_desc)
+ return -ENOMEM;
+
+ b_desc->shared_buf_ptr = shared_ptr_with_pos;
+ b_desc->usr_buf_ptr = io->user_buf;
+ b_desc->size = io->length;
+
+ if (io->flags & SE_IO_BUF_FLAGS_IS_INPUT) {
+ /*
+ * buffer is input:
+ * add an entry in the "pending input buffers" list so
+ * that copied data can be cleaned from shared memory
+ * later.
+ */
+ list_add_tail(&b_desc->link, &se_shared_mem_mgmt->pending_in);
+ } else {
+ /*
+ * buffer is output:
+ * add an entry in the "pending out buffers" list so data
+ * can be copied to user space when receiving Secure-Enclave
+ * response.
+ */
+ list_add_tail(&b_desc->link, &se_shared_mem_mgmt->pending_out);
+ }
+
+ return 0;
+}
+
+/* interface for managed res to unregister a character device */
+static void if_misc_deregister(void *miscdevice)
+{
+ misc_deregister(miscdevice);
+}
+
static int init_misc_device_context(struct se_if_priv *priv, int ch_id,
- struct se_if_device_ctx **new_dev_ctx)
+ struct se_if_device_ctx **new_dev_ctx,
+ const struct file_operations *se_if_fops)
{
struct se_if_device_ctx *dev_ctx;
int ret = 0;
@@ -220,12 +427,509 @@ static int init_misc_device_context(struct se_if_priv *priv, int ch_id,
if (!dev_ctx->devname)
return -ENOMEM;
+ mutex_init(&dev_ctx->fops_lock);
+
+ dev_ctx->priv = priv;
+ *new_dev_ctx = dev_ctx;
+
+ dev_ctx->miscdev = devm_kzalloc(priv->dev, sizeof(*dev_ctx->miscdev), GFP_KERNEL);
+ if (!dev_ctx->miscdev) {
+ *new_dev_ctx = NULL;
+ return -ENOMEM;
+ }
+
+ dev_ctx->miscdev->name = dev_ctx->devname;
+ dev_ctx->miscdev->minor = MISC_DYNAMIC_MINOR;
+ dev_ctx->miscdev->fops = se_if_fops;
+ dev_ctx->miscdev->parent = priv->dev;
+ ret = misc_register(dev_ctx->miscdev);
+ if (ret)
+ return dev_err_probe(priv->dev, ret, "Failed to register misc device.");
+
+ ret = devm_add_action_or_reset(priv->dev, if_misc_deregister, dev_ctx->miscdev);
+ if (ret)
+ return dev_err_probe(priv->dev, ret,
+ "Failed to add action to the misc-dev.");
+ return ret;
+}
+
+static int init_device_context(struct se_if_priv *priv, int ch_id,
+ struct se_if_device_ctx **new_dev_ctx)
+{
+ struct se_if_device_ctx *dev_ctx;
+ int ret = 0;
+
+ dev_ctx = kzalloc(sizeof(*dev_ctx), GFP_KERNEL);
+
+ if (!dev_ctx)
+ return -ENOMEM;
+
+ dev_ctx->devname = kasprintf(GFP_KERNEL, "%s0_ch%d",
+ get_se_if_name(priv->if_defs->se_if_type),
+ ch_id);
+ if (!dev_ctx->devname) {
+ kfree(dev_ctx);
+ return -ENOMEM;
+ }
+
+ mutex_init(&dev_ctx->fops_lock);
dev_ctx->priv = priv;
*new_dev_ctx = dev_ctx;
+ list_add_tail(&dev_ctx->link, &priv->dev_ctx_list);
+ priv->active_devctx_count++;
+
+ ret = init_se_shared_mem(dev_ctx);
+ if (ret < 0) {
+ kfree(dev_ctx->devname);
+ kfree(dev_ctx);
+ *new_dev_ctx = NULL;
+ }
+
return ret;
}
+static int se_ioctl_cmd_snd_rcv_rsp_handler(struct se_if_device_ctx *dev_ctx,
+ u64 arg)
+{
+ struct se_ioctl_cmd_snd_rcv_rsp_info cmd_snd_rcv_rsp_info = {0};
+ struct se_api_msg *tx_msg __free(kfree) = NULL;
+ struct se_api_msg *rx_msg __free(kfree) = NULL;
+ struct se_if_priv *priv = dev_ctx->priv;
+ int err = 0;
+
+ if (copy_from_user(&cmd_snd_rcv_rsp_info, (u8 __user *)arg,
+ sizeof(cmd_snd_rcv_rsp_info))) {
+ dev_err(priv->dev,
+ "%s: Failed to copy cmd_snd_rcv_rsp_info from user.",
+ dev_ctx->devname);
+ err = -EFAULT;
+ goto exit;
+ }
+
+ if (cmd_snd_rcv_rsp_info.tx_buf_sz < SE_MU_HDR_SZ) {
+ dev_err(priv->dev, "%s: User buffer too small(%d < %d)",
+ dev_ctx->devname, cmd_snd_rcv_rsp_info.tx_buf_sz, SE_MU_HDR_SZ);
+ err = -ENOSPC;
+ goto exit;
+ }
+
+ rx_msg = kzalloc(cmd_snd_rcv_rsp_info.rx_buf_sz, GFP_KERNEL);
+ if (!rx_msg) {
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ tx_msg = memdup_user(cmd_snd_rcv_rsp_info.tx_buf,
+ cmd_snd_rcv_rsp_info.tx_buf_sz);
+ if (IS_ERR(tx_msg)) {
+ err = PTR_ERR(tx_msg);
+ goto exit;
+ }
+
+ if (tx_msg->header.tag != priv->if_defs->cmd_tag) {
+ err = -EINVAL;
+ goto exit;
+ }
+
+ if (tx_msg->header.ver == priv->if_defs->fw_api_ver &&
+ get_load_fw_instance(priv)->is_fw_tobe_loaded) {
+ err = se_load_firmware(priv);
+ if (err) {
+ dev_err(priv->dev, "Could not send msg as FW is not loaded.");
+ err = -EPERM;
+ goto exit;
+ }
+ }
+ set_se_rcv_msg_timeout(priv, SE_RCV_MSG_LONG_TIMEOUT);
+
+ err = ele_msg_send_rcv(dev_ctx, tx_msg, cmd_snd_rcv_rsp_info.tx_buf_sz,
+ rx_msg, cmd_snd_rcv_rsp_info.rx_buf_sz);
+ if (err < 0)
+ goto exit;
+
+ dev_dbg(priv->dev, "%s: %s %s.", dev_ctx->devname, __func__,
+ "message received, start transmit to user");
+
+ /* We may need to copy the output data to user before
+ * delivering the completion message.
+ */
+ err = se_dev_ctx_cpy_out_data(dev_ctx);
+ if (err < 0)
+ goto exit;
+
+ /* Copy data from the buffer */
+ print_hex_dump_debug("to user ", DUMP_PREFIX_OFFSET, 4, 4, rx_msg,
+ cmd_snd_rcv_rsp_info.rx_buf_sz, false);
+
+ if (copy_to_user(cmd_snd_rcv_rsp_info.rx_buf, rx_msg,
+ cmd_snd_rcv_rsp_info.rx_buf_sz)) {
+ dev_err(priv->dev, "%s: Failed to copy to user.", dev_ctx->devname);
+ err = -EFAULT;
+ }
+
+exit:
+
+ /* shared memory is allocated before this IOCTL */
+ se_dev_ctx_shared_mem_cleanup(dev_ctx);
+
+ if (copy_to_user((void __user *)arg, &cmd_snd_rcv_rsp_info,
+ sizeof(cmd_snd_rcv_rsp_info))) {
+ dev_err(priv->dev, "%s: Failed to copy cmd_snd_rcv_rsp_info from user.",
+ dev_ctx->devname);
+ err = -EFAULT;
+ }
+
+ return err;
+}
+
+static int se_ioctl_get_mu_info(struct se_if_device_ctx *dev_ctx,
+ u64 arg)
+{
+ struct se_if_priv *priv = dev_ctx->priv;
+ struct se_ioctl_get_if_info if_info;
+ struct se_if_node *if_node;
+ int err = 0;
+
+ if_node = container_of(priv->if_defs, typeof(*if_node), if_defs);
+
+ if_info.se_if_id = 0;
+ if_info.interrupt_idx = 0;
+ if_info.tz = 0;
+ if_info.did = 0;
+ if_info.cmd_tag = priv->if_defs->cmd_tag;
+ if_info.rsp_tag = priv->if_defs->rsp_tag;
+ if_info.success_tag = priv->if_defs->success_tag;
+ if_info.base_api_ver = priv->if_defs->base_api_ver;
+ if_info.fw_api_ver = priv->if_defs->fw_api_ver;
+
+ dev_dbg(priv->dev, "%s: info [se_if_id: %d, irq_idx: %d, tz: 0x%x, did: 0x%x].",
+ dev_ctx->devname, if_info.se_if_id, if_info.interrupt_idx, if_info.tz,
+ if_info.did);
+
+ if (copy_to_user((u8 __user *)arg, &if_info, sizeof(if_info))) {
+ dev_err(priv->dev, "%s: Failed to copy mu info to user.",
+ dev_ctx->devname);
+ err = -EFAULT;
+ }
+
+ return err;
+}
+
+/*
+ * Copy a buffer of data to/from the user and return the address to use in
+ * messages
+ */
+static int se_ioctl_setup_iobuf_handler(struct se_if_device_ctx *dev_ctx,
+ u64 arg)
+{
+ struct se_shared_mem *shared_mem = NULL;
+ struct se_ioctl_setup_iobuf io = {0};
+ int err = 0;
+ u32 pos;
+
+ if (copy_from_user(&io, (u8 __user *)arg, sizeof(io))) {
+ dev_err(dev_ctx->priv->dev, "%s: Failed copy iobuf config from user.",
+ dev_ctx->devname);
+ return -EFAULT;
+ }
+
+ dev_dbg(dev_ctx->priv->dev, "%s: io [buf: %p(%d) flag: %x].", dev_ctx->devname,
+ io.user_buf, io.length, io.flags);
+
+ if (io.length == 0 || !io.user_buf) {
+ /*
+ * Accept NULL pointers since some buffers are optional
+ * in FW commands. In this case we should return 0 as
+ * pointer to be embedded into the message.
+ * Skip all data copy part of code below.
+ */
+ io.ele_addr = 0;
+ goto copy;
+ }
+
+ /* No specific requirement for this buffer. */
+ shared_mem = &dev_ctx->se_shared_mem_mgmt.non_secure_mem;
+
+ /* Check there is enough space in the shared memory. */
+ dev_dbg(dev_ctx->priv->dev, "%s: req_size = %d, max_size= %d, curr_pos = %d",
+ dev_ctx->devname, round_up(io.length, 8u), shared_mem->size,
+ shared_mem->pos);
+
+ if (shared_mem->size < shared_mem->pos ||
+ round_up(io.length, 8u) > (shared_mem->size - shared_mem->pos)) {
+ dev_err(dev_ctx->priv->dev, "%s: Not enough space in shared memory.",
+ dev_ctx->devname);
+ return -ENOMEM;
+ }
+
+ /* Allocate space in shared memory. 8 bytes aligned. */
+ pos = shared_mem->pos;
+ shared_mem->pos += round_up(io.length, 8u);
+ io.ele_addr = (u64)shared_mem->dma_addr + pos;
+
+ memset(shared_mem->ptr + pos, 0, io.length);
+ if ((io.flags & SE_IO_BUF_FLAGS_IS_INPUT) ||
+ (io.flags & SE_IO_BUF_FLAGS_IS_IN_OUT)) {
+ /*
+ * buffer is input:
+ * copy data from user space to this allocated buffer.
+ */
+ if (copy_from_user(shared_mem->ptr + pos, io.user_buf, io.length)) {
+ dev_err(dev_ctx->priv->dev,
+ "%s: Failed copy data to shared memory.",
+ dev_ctx->devname);
+ return -EFAULT;
+ }
+ }
+
+ err = add_b_desc_to_pending_list(shared_mem->ptr + pos, &io, dev_ctx);
+ if (err < 0)
+ dev_err(dev_ctx->priv->dev, "%s: Failed to allocate/link b_desc.",
+ dev_ctx->devname);
+
+copy:
+ /* Provide the EdgeLock Enclave address to user space only if success.*/
+ if (copy_to_user((u8 __user *)arg, &io, sizeof(io))) {
+ dev_err(dev_ctx->priv->dev, "%s: Failed to copy iobuff setup to user.",
+ dev_ctx->devname);
+ err = -EFAULT;
+ }
+
+ return err;
+}
+
+/* IOCTL to provide SoC information */
+static int se_ioctl_get_se_soc_info_handler(struct se_if_device_ctx *dev_ctx, u64 arg)
+{
+ struct se_ioctl_get_soc_info soc_info;
+ int err = -EINVAL;
+
+ soc_info.soc_id = get_se_soc_id(dev_ctx->priv);
+ soc_info.soc_rev = var_se_info.soc_rev;
+
+ err = copy_to_user((u8 __user *)arg, (u8 *)(&soc_info), sizeof(soc_info));
+ if (err) {
+ dev_err(dev_ctx->priv->dev, "%s: Failed to copy soc info to user.",
+ dev_ctx->devname);
+ err = -EFAULT;
+ }
+
+ return err;
+}
+
+/*
+ * File operations for user-space
+ */
+
+/* Write a message to the MU. */
+static ssize_t se_if_fops_write(struct file *fp, const char __user *buf,
+ size_t size, loff_t *ppos)
+{
+ struct se_if_device_ctx *dev_ctx = fp->private_data;
+ struct se_api_msg *tx_msg __free(kfree) = NULL;
+ struct se_if_priv *priv = dev_ctx->priv;
+ int err;
+
+ dev_dbg(priv->dev, "%s: write from buf (%p)%zu, ppos=%lld.", dev_ctx->devname,
+ buf, size, ((ppos) ? *ppos : 0));
+
+ scoped_cond_guard(mutex_intr, return -EBUSY, &dev_ctx->fops_lock) {
+ if (dev_ctx != priv->cmd_receiver_clbk_hdl.dev_ctx)
+ return -EINVAL;
+
+ if (size < SE_MU_HDR_SZ) {
+ dev_err(priv->dev, "%s: User buffer too small(%zu < %d).",
+ dev_ctx->devname, size, SE_MU_HDR_SZ);
+ return -ENOSPC;
+ }
+
+ tx_msg = memdup_user(buf, size);
+ if (IS_ERR(tx_msg))
+ return PTR_ERR(tx_msg);
+
+ print_hex_dump_debug("from user ", DUMP_PREFIX_OFFSET, 4, 4,
+ tx_msg, size, false);
+
+ err = ele_msg_send(dev_ctx, tx_msg, size);
+
+ return err;
+ }
+}
+
+/*
+ * Read a message from the MU.
+ * Blocking until a message is available.
+ */
+static ssize_t se_if_fops_read(struct file *fp, char __user *buf, size_t size,
+ loff_t *ppos)
+{
+ struct se_if_device_ctx *dev_ctx = fp->private_data;
+ struct se_if_priv *priv = dev_ctx->priv;
+ int err;
+
+ dev_dbg(priv->dev, "%s: read to buf %p(%zu), ppos=%lld.", dev_ctx->devname,
+ buf, size, ((ppos) ? *ppos : 0));
+
+ scoped_cond_guard(mutex_intr, return -EBUSY, &dev_ctx->fops_lock) {
+ if (dev_ctx != priv->cmd_receiver_clbk_hdl.dev_ctx) {
+ err = -EINVAL;
+ goto exit;
+ }
+
+ err = ele_msg_rcv(dev_ctx, &priv->cmd_receiver_clbk_hdl);
+ if (err < 0) {
+ dev_err(priv->dev, "%s: Err[0x%x]:Interrupted by signal."
+ "Current active dev-ctx count = %d.",
+ dev_ctx->devname, err, dev_ctx->priv->active_devctx_count);
+ goto exit;
+ }
+
+ /* We may need to copy the output data to user before
+ * delivering the completion message.
+ */
+ err = se_dev_ctx_cpy_out_data(dev_ctx);
+ if (err < 0)
+ goto exit;
+
+ /* Copy data from the buffer */
+ print_hex_dump_debug("to user ", DUMP_PREFIX_OFFSET, 4, 4,
+ priv->cmd_receiver_clbk_hdl.rx_msg,
+ priv->cmd_receiver_clbk_hdl.rx_msg_sz,
+ false);
+
+ if (copy_to_user(buf, priv->cmd_receiver_clbk_hdl.rx_msg,
+ priv->cmd_receiver_clbk_hdl.rx_msg_sz)) {
+ dev_err(priv->dev, "%s: Failed to copy to user.",
+ dev_ctx->devname);
+ err = -EFAULT;
+ } else {
+ err = priv->cmd_receiver_clbk_hdl.rx_msg_sz;
+ }
+exit:
+ priv->cmd_receiver_clbk_hdl.rx_msg_sz = 0;
+
+ se_dev_ctx_shared_mem_cleanup(dev_ctx);
+
+ return err;
+ }
+}
+
+/* Open a character device. */
+static int se_if_fops_open(struct inode *nd, struct file *fp)
+{
+ struct miscdevice *miscdev = fp->private_data;
+ struct se_if_device_ctx *misc_dev_ctx;
+ struct se_if_device_ctx *dev_ctx;
+ struct se_if_priv *priv;
+ int err = 0;
+
+ priv = dev_get_drvdata(miscdev->parent);
+ misc_dev_ctx = priv->priv_dev_ctx;
+
+ scoped_cond_guard(mutex_intr, return -EBUSY, &misc_dev_ctx->fops_lock) {
+ priv->dev_ctx_mono_count++;
+ err = init_device_context(priv,
+ priv->dev_ctx_mono_count ?
+ priv->dev_ctx_mono_count
+ : priv->dev_ctx_mono_count++,
+ &dev_ctx);
+ if (err)
+ dev_err(priv->dev, "Failed[0x%x] to create dev-ctx.", err);
+ else
+ fp->private_data = dev_ctx;
+
+ return err;
+ }
+}
+
+/* Close a character device. */
+static int se_if_fops_close(struct inode *nd, struct file *fp)
+{
+ struct se_if_device_ctx *dev_ctx = fp->private_data;
+ struct se_if_priv *priv = dev_ctx->priv;
+
+ scoped_cond_guard(mutex_intr, return -EBUSY, &dev_ctx->fops_lock) {
+ /* check if this device was registered as command receiver. */
+ if (priv->cmd_receiver_clbk_hdl.dev_ctx == dev_ctx) {
+ priv->cmd_receiver_clbk_hdl.dev_ctx = NULL;
+ kfree(priv->cmd_receiver_clbk_hdl.rx_msg);
+ priv->cmd_receiver_clbk_hdl.rx_msg = NULL;
+ }
+
+ se_dev_ctx_shared_mem_cleanup(dev_ctx);
+ cleanup_se_shared_mem(dev_ctx);
+
+ priv->active_devctx_count--;
+ list_del(&dev_ctx->link);
+
+ kfree(dev_ctx->devname);
+ kfree(dev_ctx);
+ }
+
+ return 0;
+}
+
+/* IOCTL entry point of a character device */
+static long se_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
+{
+ struct se_if_device_ctx *dev_ctx = fp->private_data;
+ struct se_if_priv *priv = dev_ctx->priv;
+ long err;
+
+ /* Prevent race during change of device context */
+ scoped_cond_guard(mutex_intr, return -EBUSY, &dev_ctx->fops_lock) {
+ switch (cmd) {
+ case SE_IOCTL_ENABLE_CMD_RCV:
+ if (!priv->cmd_receiver_clbk_hdl.dev_ctx) {
+ if (!priv->cmd_receiver_clbk_hdl.rx_msg) {
+ priv->cmd_receiver_clbk_hdl.rx_msg =
+ kzalloc(MAX_NVM_MSG_LEN,
+ GFP_KERNEL);
+ if (!priv->cmd_receiver_clbk_hdl.rx_msg) {
+ err = -ENOMEM;
+ break;
+ }
+ }
+ priv->cmd_receiver_clbk_hdl.rx_msg_sz = MAX_NVM_MSG_LEN;
+ priv->cmd_receiver_clbk_hdl.dev_ctx = dev_ctx;
+ err = 0;
+ } else {
+ err = -EBUSY;
+ }
+ break;
+ case SE_IOCTL_GET_MU_INFO:
+ err = se_ioctl_get_mu_info(dev_ctx, arg);
+ break;
+ case SE_IOCTL_SETUP_IOBUF:
+ err = se_ioctl_setup_iobuf_handler(dev_ctx, arg);
+ break;
+ case SE_IOCTL_GET_SOC_INFO:
+ err = se_ioctl_get_se_soc_info_handler(dev_ctx, arg);
+ break;
+ case SE_IOCTL_CMD_SEND_RCV_RSP:
+ err = se_ioctl_cmd_snd_rcv_rsp_handler(dev_ctx, arg);
+ break;
+ default:
+ err = -EINVAL;
+ dev_dbg(priv->dev, "%s: IOCTL %.8x not supported.",
+ dev_ctx->devname, cmd);
+ }
+ }
+
+ return err;
+}
+
+/* Char driver setup */
+static const struct file_operations se_if_fops = {
+ .open = se_if_fops_open,
+ .owner = THIS_MODULE,
+ .release = se_if_fops_close,
+ .unlocked_ioctl = se_ioctl,
+ .read = se_if_fops_read,
+ .write = se_if_fops_write,
+};
+
/* interface for managed res to free a mailbox channel */
static void if_mbox_free_channel(void *mbox_chan)
{
@@ -246,7 +950,7 @@ static int se_if_request_channel(struct device *dev, struct mbox_chan **chan,
ret = devm_add_action_or_reset(dev, if_mbox_free_channel, t_chan);
if (ret)
return dev_err_probe(dev, -EPERM,
- "Failed to add-action for removal of mbox: %s\n",
+ "Failed to add-action for removal of mbox: %s.",
name);
*chan = t_chan;
@@ -255,6 +959,7 @@ static int se_if_request_channel(struct device *dev, struct mbox_chan **chan,
static void se_if_probe_cleanup(void *plat_dev)
{
+ struct se_if_device_ctx *dev_ctx, *t_dev_ctx;
struct platform_device *pdev = plat_dev;
struct se_fw_load_info *load_fw;
struct device *dev = &pdev->dev;
@@ -279,6 +984,13 @@ static void se_if_probe_cleanup(void *plat_dev)
load_fw->imem.buf = NULL;
}
+ if (priv->dev_ctx_mono_count) {
+ list_for_each_entry_safe(dev_ctx, t_dev_ctx, &priv->dev_ctx_list, link) {
+ list_del(&dev_ctx->link);
+ priv->active_devctx_count--;
+ }
+ }
+
/*
* No need to check, if reserved memory is allocated
* before calling for its release. Or clearing the
@@ -319,6 +1031,7 @@ static int se_if_probe(struct platform_device *pdev)
priv->se_mb_cl.tx_block = false;
priv->se_mb_cl.knows_txdone = true;
priv->se_mb_cl.rx_callback = se_if_rx_callback;
+ set_se_rcv_msg_timeout(priv, SE_RCV_MSG_DEFAULT_TIMEOUT);
ret = se_if_request_channel(dev, &priv->tx_chan, &priv->se_mb_cl, MBOX_TX_NAME);
if (ret)
@@ -340,6 +1053,7 @@ static int se_if_probe(struct platform_device *pdev)
"Unable to get sram pool = %s.",
if_node->pool_name);
}
+ INIT_LIST_HEAD(&priv->dev_ctx_list);
if (if_node->reserved_dma_ranges) {
ret = of_reserved_mem_device_init(dev);
@@ -348,7 +1062,7 @@ static int se_if_probe(struct platform_device *pdev)
"Failed to init reserved memory region.");
}
- ret = init_misc_device_context(priv, 0, &priv->priv_dev_ctx);
+ ret = init_misc_device_context(priv, 0, &priv->priv_dev_ctx, &se_if_fops);
if (ret)
return dev_err_probe(dev, ret,
"Failed[0x%x] to create device contexts.",
@@ -389,6 +1103,7 @@ static int se_suspend(struct device *dev)
struct se_fw_load_info *load_fw;
int ret = 0;
+ set_se_rcv_msg_timeout(priv, SE_RCV_MSG_DEFAULT_TIMEOUT);
load_fw = get_load_fw_instance(priv);
if (load_fw->imem_mgmt)
diff --git a/drivers/firmware/imx/se_ctrl.h b/drivers/firmware/imx/se_ctrl.h
index b5e7705e2f26..5fcdcfe3e8e5 100644
--- a/drivers/firmware/imx/se_ctrl.h
+++ b/drivers/firmware/imx/se_ctrl.h
@@ -14,6 +14,7 @@
#define SE_MSG_WORD_SZ 0x4
#define RES_STATUS(x) FIELD_GET(0x000000ff, x)
+#define MAX_DATA_SIZE_PER_USER (65 * 1024)
#define MAX_NVM_MSG_LEN (256)
#define MESSAGING_VERSION_6 0x6
#define MESSAGING_VERSION_7 0x7
@@ -37,10 +38,38 @@ struct se_imem_buf {
u32 state;
};
+struct se_buf_desc {
+ u8 *shared_buf_ptr;
+ void __user *usr_buf_ptr;
+ u32 size;
+ struct list_head link;
+};
+
+struct se_shared_mem {
+ dma_addr_t dma_addr;
+ u32 size;
+ u32 pos;
+ u8 *ptr;
+};
+
+struct se_shared_mem_mgmt_info {
+ struct list_head pending_in;
+ struct list_head pending_out;
+
+ struct se_shared_mem non_secure_mem;
+};
+
/* Private struct for each char device instance. */
struct se_if_device_ctx {
struct se_if_priv *priv;
+ struct miscdevice *miscdev;
const char *devname;
+
+ /* process one file operation at a time. */
+ struct mutex fops_lock;
+
+ struct se_shared_mem_mgmt_info se_shared_mem_mgmt;
+ struct list_head link;
};
/* Header of the messages exchange with the EdgeLock Enclave */
@@ -89,6 +118,10 @@ struct se_if_priv {
const struct se_if_defines *if_defs;
struct se_if_device_ctx *priv_dev_ctx;
+ struct list_head dev_ctx_list;
+ u32 active_devctx_count;
+ u32 dev_ctx_mono_count;
+ u32 se_rcv_msg_timeout_ms;
};
char *get_se_if_name(u8 se_if_id);
diff --git a/include/uapi/linux/se_ioctl.h b/include/uapi/linux/se_ioctl.h
new file mode 100644
index 000000000000..0c948bdc8c26
--- /dev/null
+++ b/include/uapi/linux/se_ioctl.h
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause*/
+/*
+ * Copyright 2025 NXP
+ */
+
+#ifndef SE_IOCTL_H
+#define SE_IOCTL_H
+
+#include <linux/types.h>
+
+#define SE_TYPE_STR_DBG "dbg"
+#define SE_TYPE_STR_HSM "hsm"
+#define SE_TYPE_ID_UNKWN 0x0
+#define SE_TYPE_ID_DBG 0x1
+#define SE_TYPE_ID_HSM 0x2
+/* IOCTL definitions. */
+
+struct se_ioctl_setup_iobuf {
+ void __user *user_buf;
+ __u32 length;
+ __u32 flags;
+ __u64 ele_addr;
+};
+
+struct se_ioctl_shared_mem_cfg {
+ __u32 base_offset;
+ __u32 size;
+};
+
+struct se_ioctl_get_if_info {
+ __u8 se_if_id;
+ __u8 interrupt_idx;
+ __u8 tz;
+ __u8 did;
+ __u8 cmd_tag;
+ __u8 rsp_tag;
+ __u8 success_tag;
+ __u8 base_api_ver;
+ __u8 fw_api_ver;
+};
+
+struct se_ioctl_cmd_snd_rcv_rsp_info {
+ __u32 __user *tx_buf;
+ int tx_buf_sz;
+ __u32 __user *rx_buf;
+ int rx_buf_sz;
+};
+
+struct se_ioctl_get_soc_info {
+ __u16 soc_id;
+ __u16 soc_rev;
+};
+
+/* IO Buffer Flags */
+#define SE_IO_BUF_FLAGS_IS_OUTPUT (0x00u)
+#define SE_IO_BUF_FLAGS_IS_INPUT (0x01u)
+#define SE_IO_BUF_FLAGS_USE_SEC_MEM (0x02u)
+#define SE_IO_BUF_FLAGS_USE_SHORT_ADDR (0x04u)
+#define SE_IO_BUF_FLAGS_IS_IN_OUT (0x10u)
+
+/* IOCTLS */
+#define SE_IOCTL 0x0A /* like MISC_MAJOR. */
+
+/*
+ * ioctl to designated the current fd as logical-reciever.
+ * This is ioctl is send when the nvm-daemon, a slave to the
+ * firmware is started by the user.
+ */
+#define SE_IOCTL_ENABLE_CMD_RCV _IO(SE_IOCTL, 0x01)
+
+/*
+ * ioctl to get the buffer allocated from the memory, which is shared
+ * between kernel and FW.
+ * Post allocation, the kernel tagged the allocated memory with:
+ * Output
+ * Input
+ * Input-Output
+ * Short address
+ * Secure-memory
+ */
+#define SE_IOCTL_SETUP_IOBUF _IOWR(SE_IOCTL, 0x03, struct se_ioctl_setup_iobuf)
+
+/*
+ * ioctl to get the mu information, that is used to exchange message
+ * with FW, from user-spaced.
+ */
+#define SE_IOCTL_GET_MU_INFO _IOR(SE_IOCTL, 0x04, struct se_ioctl_get_if_info)
+/*
+ * ioctl to get SoC Info from user-space.
+ */
+#define SE_IOCTL_GET_SOC_INFO _IOR(SE_IOCTL, 0x06, struct se_ioctl_get_soc_info)
+
+/*
+ * ioctl to send command and receive response from user-space.
+ */
+#define SE_IOCTL_CMD_SEND_RCV_RSP _IOWR(SE_IOCTL, 0x07, struct se_ioctl_cmd_snd_rcv_rsp_info)
+#endif
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v19 6/7] arm64: dts: imx8ulp: add secure enclave node
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
` (4 preceding siblings ...)
2025-09-26 21:09 ` [PATCH v19 5/7] firmware: drivers: imx: adds miscdev Pankaj Gupta
@ 2025-09-26 21:09 ` Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 7/7] arm64: dts: imx8ulp-evk: add reserved memory property Pankaj Gupta
` (2 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-09-26 21:09 UTC (permalink / raw)
To: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel,
Frank Li
Add support for NXP secure enclave called EdgeLock Enclave firmware (se-fw)
for imx8ulp-evk.
Add label sram0 for sram@2201f000 and add secure-enclave node
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 13b01f3aa2a4..10a4779dd24c 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * Copyright 2021 NXP
+ * Copyright 2021, 2025 NXP
*/
#include <dt-bindings/clock/imx8ulp-clock.h>
@@ -154,7 +154,7 @@ sosc: clock-sosc {
#clock-cells = <0>;
};
- sram@2201f000 {
+ sram0: sram@2201f000 {
compatible = "mmio-sram";
reg = <0x0 0x2201f000 0x0 0x1000>;
@@ -186,6 +186,13 @@ scmi_sensor: protocol@15 {
#thermal-sensor-cells = <1>;
};
};
+
+ hsm0: secure-enclave {
+ compatible = "fsl,imx8ulp-se-ele-hsm";
+ mbox-names = "tx", "rx";
+ mboxes = <&s4muap 0 0>, <&s4muap 1 0>;
+ sram = <&sram0>;
+ };
};
cm33: remoteproc-cm33 {
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v19 7/7] arm64: dts: imx8ulp-evk: add reserved memory property
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
` (5 preceding siblings ...)
2025-09-26 21:09 ` [PATCH v19 6/7] arm64: dts: imx8ulp: add secure enclave node Pankaj Gupta
@ 2025-09-26 21:09 ` Pankaj Gupta
2025-10-16 2:20 ` [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Peng Fan
2025-10-16 11:41 ` Marco Felsch
8 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-09-26 21:09 UTC (permalink / raw)
To: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel,
Frank Li
Reserve 1MB of DDR memory region due to EdgeLock Enclave's hardware
limitation restricting access to DDR addresses from 0x80000000
to 0xafffffff.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 290a49bea2f7..10aaf02f8ea7 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * Copyright 2021 NXP
+ * Copyright 2021, 2025 NXP
*/
/dts-v1/;
@@ -37,6 +37,12 @@ linux,cma {
linux,cma-default;
};
+ ele_reserved: memory@90000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x90000000 0 0x100000>;
+ no-map;
+ };
+
m33_reserved: noncacheable-section@a8600000 {
reg = <0 0xa8600000 0 0x1000000>;
no-map;
@@ -259,6 +265,10 @@ &usdhc0 {
status = "okay";
};
+&hsm0 {
+ memory-region = <&ele_reserved>;
+};
+
&fec {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_enet>;
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
` (6 preceding siblings ...)
2025-09-26 21:09 ` [PATCH v19 7/7] arm64: dts: imx8ulp-evk: add reserved memory property Pankaj Gupta
@ 2025-10-16 2:20 ` Peng Fan
2025-10-16 11:41 ` Marco Felsch
8 siblings, 0 replies; 17+ messages in thread
From: Peng Fan @ 2025-10-16 2:20 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel,
Frank Li
On Sat, Sep 27, 2025 at 02:39:30AM +0530, Pankaj Gupta wrote:
>
>---
>Pankaj Gupta (7):
> Documentation/firmware: add imx/se to other_interfaces
> dt-bindings: arm: fsl: add imx-se-fw binding doc
> firmware: imx: add driver for NXP EdgeLock Enclave
> firmware: imx: device context dedicated to priv
> firmware: drivers: imx: adds miscdev
> arm64: dts: imx8ulp: add secure enclave node
> arm64: dts: imx8ulp-evk: add reserved memory property
>
Tested-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-09-26 21:09 [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Pankaj Gupta
` (7 preceding siblings ...)
2025-10-16 2:20 ` [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave Peng Fan
@ 2025-10-16 11:41 ` Marco Felsch
2025-10-27 6:43 ` [EXT] " Pankaj Gupta
8 siblings, 1 reply; 17+ messages in thread
From: Marco Felsch @ 2025-10-16 11:41 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree, imx, linux-doc, Frank Li, linux-kernel,
linux-arm-kernel
Hi,
On 25-09-27, Pankaj Gupta wrote:
> Highlight:
>
> There are long discussion at V18 with Marco Felsch.
> https://lore.kernel.org/imx/AM9PR04MB8604F5A7DD8B1E41FDAD09039501A@AM9PR04MB
> 8604.eurprd04.prod.outlook.com/
>
> The key point is about using OP-TEE OS.
>
> Marco's questions:
> =================
> Q1. Both MU(s) from each world - Secure & Non-secure, cannot be used
> simultaneously. Why?
> A1. ELE FW fix is available, where concurrent access to ELE from both the
> world is working. This fix is not required for the current patch-set for
> i.MX8ULP.
According https://github.com/OP-TEE/optee_os/pull/7268/commits/83b516edc0270ca8300ce524a0c3d560e67a0f48#r1955899462
there is no fix yet. Can you please point me to the fixed version?
Also can you please outline why the fix is not required for i.MX8ULP?
Unfortunately I can't remember.
> Q2. How is the secure and non-secure world talk to the ELE if there is only
> one MU?
> A2. From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for
> each world - Linux(one or more) and OP-TEE OS (one or more). Has updated
> the commit message of 3/7.
Does apply to the i.MX8ULP SoC as well? The NXP name scheme isn't very
easy to follow.
> Q3. How exactly do the eFuse write access after the device was locked down,
> will be provided with single path; for the following case?
> - For a verified boot setup, you need to burn an eFuse at some point,
> to tell the bootROM to boot only correct verified firmware images.
> - After this lockdown, it's no longer possible to burn eFuses from the
> REE, while the production line setup still requires the support.
> A3. OP-TEE OS supports read fuses, currently as part of our quarterly release.
> Write fuse will be in coming release. Please note that the current patch-
> set does not contain any read/write eFuse feature.
But one of your patches is mention it, right? So there will be still two
paths.
Also according your IOCTL docuementation you want to expose the whole
device to the user-space?
| What: /dev/<se>_mu[0-9]+_ch[0-9]+
| Date: Mar 2025
| KernelVersion: 6.8
| Contact: linux-imx@nxp.com, pankaj.gupta@nxp.com
| Description:
| NXP offers multiple hardware IP(s) for secure enclaves like EdgeLock-
| Enclave(ELE), SECO. The character device file descriptors
| /dev/<se>_mu*_ch* are the interface between userspace NXP's secure-
| enclave shared library and the kernel driver.
|
| The ioctl(2)-based ABI is defined and documented in
| [include]<linux/firmware/imx/ele_mu_ioctl.h>.
| ioctl(s) are used primarily for:
| - shared memory management
| - allocation of I/O buffers
| - getting mu info
| - setting a dev-ctx as receiver to receive all the commands from FW
| - getting SoC info
| - send command and receive command response
^
This is a rather uncommon approach. The kernel has interfaces to
abstract hardware. You completely bypass this if you expose everything
to the userspace.
> Q4. What is the ELE behavior if the secure-world stresses the ELE? Is there
> a MU priority so the normal-world MU may get blocked (never addressed)
> or are both MUs scheduled in round-robin?
> A4. ELE will pick the message from Both MU(s), based on FIFO.
This doesn't answer my question. How gets the FIFO filled? If the one of
both worlds aways keep the MU busy?
> Q5. Why ELE performance matters?
> - On i.MX8M, which uses the CAAM (the ELE predecessor), It can be
> verified that the ARMv8 CE are much faster than the crypto-engine itself.
> Therefore the CAAM is mostly unused.
> A5. User looks for both type of implementation based on their usecase:
> - Certain users still offload to CAAM, to save their ARM CPU cycles for
> other priority tasks.
I have never seen such designs but okay.
> - While certain customer choose ARM-CE for the crypto offloads for better
> performance.
> As far as ELE is concerned, it is not a crypto accelerator like CAAM.
> Performance hungry crypto-ops are not recommended to be offloaded to ELE.
I don't get this point. So NXP doesn't recommend to use the ELE for
crypt-ops?
> Q6. For the IOT-cases where real-time encrypted feed from sensors, will take
> latency hit, Does the ELE support inline en-/decryption?
> A6. Yes, ELE support Inline Encryption Engine (IEE), starting i.MX95 onwards.
May I ask, how is this connected and which interfaces are connected to
the IEE? I would have checked it by myself but unfortunately NXP doesn't
provide a TRM for the i.MX95 yet.
> Marco's Suggestions/NXP response:
> ================================
> S1. Below listed ELE access requirements, can be done from OP-TEE OS in all
> the Life-Cycle states. then Why to use Linux?
> - eFuse access (done via OP-TEE OS i.MX specific PTA): OTP eFuse R/W access
> after doing the LOCK_DOWN fuse is no longer possible without OP-TEE OS. This
> involves general purpose (GP) eFuses too.
> - ELE ping every 1 day (kernel SMC WDG driver, OP-TEE OS wd driver).
> - HW-RNG (kernel HWRNG driver + OP-TEE OS HWRNG PTA).
> R1. There are i.MX9* users, that are not using OP-TEE OS, but still want
> to use ELE features from Linux. So, these users are requesting for this
> driver in Linux.
Which ELE features?
> As suggested by you, writing to eFuse after life-cycle closed state, the
> driver in OP-TEE OS is needed.
> Though there are other OP-TEE OS features too, that needs to be offloaded
> to HSM, for security reasons, like:
> - Hardware Unique Key(HUK) getting generated.
> - OP-TEE OS's ASLR seed generation.
We're talking about features the normal world wants to have access too,
since you said ".. but still want to use ELE feature from Linux ..". The
HUK and the TEE ASLR seed is clearly not something Linux wants to have
access too.
> S2. Having one implementation is beneficial in the following ways:
> - Multiple paths also requires more maintain- and testing effort.
> - FW files with having +1 FW for the new i.MX9*, where there are plenty
> already eg.: bootloader, TF-A, ele-fw, scu-fw (i.MX95), increases the
> maintenance on both the paths.
> - TEE code could be reused by other OSes.
> - TEE is used anyway for new projects due to CRA and friends
> R2. As conveyed in R1, there are Linux only users, that are dependent on SE
> Linux kernel driver.
What difference does it make if these Linux-only users get the ELE
access via OP-TEE? It's just one binary more.
> S3. Having one implementation is beneficial in the following ways:
> - Adding the support for it to OP-TEE OS do not requires ELE-FW.
I never said that this requires no ELE FW! I said it requires no ELE-FW
update! Was the update already rolled out?
> - Concurrent access handling is done by the TEE core.
> R3. As already mentioned that ELE FW fix is available, for concurrent access.
> Please note that FW fix is not required for the current patch-set.
Can you provide us a link to the fix please? The fix should fix the
concurrent normal-world <-> secure-world MU access issue. Why is this
fix not required if I have a running OP-TEE?
> S4. This series causes more confusions till the ELE FW fix is available to
> allow concurrent access to ELE from both the worlds.
> R4. FW fix is already available, and concurrent access is enabled by default
> in LF Q3'25, release. Please note that FW fix is not required for the
> current patch-set.
Please provide a link to the new FW and why is the fix nor required for
this patchset?
> S5. Suggesting to add the OP-TEE OS support for the required features e.g. eFuses,
> watchdog, HWRNG. The whole Linux part is mostly in place.
> R5. Yes, the secure world features like eFuse read/write will be added
> to OP-TEE OS. Please note that this patch-set does not contain any read/write
> eFuse feature.
I see, instead it expose the whole ELE to the userspace if I got it
correct according your IOCTL documentation. This would be even worse.
Regards,
Marco
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [EXT] Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-10-16 11:41 ` Marco Felsch
@ 2025-10-27 6:43 ` Pankaj Gupta
2025-11-03 19:08 ` Marco Felsch
0 siblings, 1 reply; 17+ messages in thread
From: Pankaj Gupta @ 2025-10-27 6:43 UTC (permalink / raw)
To: Marco Felsch
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-doc@vger.kernel.org, Frank Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
On 25-09-27, Pankaj Gupta wrote:
>> Highlight:
>>
>> There are long discussion at V18 with Marco Felsch.
>> https://lore.kernel.org/imx/AM9PR04MB8604F5A7DD8B1E41FDAD09039501A@AM9PR04MB
>> 8604.eurprd04.prod.outlook.com/
>>
>> The key point is about using OP-TEE OS.
>>
>> Marco's questions:
>> =================
>> Q1. Both MU(s) from each world - Secure & Non-secure, cannot be used
>> simultaneously. Why?
>> A1. ELE FW fix is available, where concurrent access to ELE from both the
>> world is working. This fix is not required for the current patch-set for
>> i.MX8ULP.
> According https://github.com/OP-TEE/optee_os/pull/7268/commits/83b516edc0270ca8300ce524a0c3d560e67a0f48#r1955899462
> there is no fix yet. Can you please point me to the fixed version?
It is not yet up-streamed to OPTEE-OS repo.
Fix version is part of NXP LF Q3 released on 30 September.
Commit can be found on this URL: https://github.com/nxp-imx/imx-optee-os/commits/lf-6.12.34_2.1.0/.
One more fix is coming in LF Q4. After that, these patches will up-streamed to OP-TEE-OS.
Then you will be able locate it in OPTEE-OS git repo.
Since the current Patch-set is for i.MX8ULP, where concurrent access from both the world is not possible.
In context to i.MX93, for OPTEE-OS patches, request you to please discuss in OPTEE community. Not here.
> Also, can you please outline why the fix is not required for i.MX8ULP?
> Unfortunately I can't remember.
There is no Trust-MU for OPTEE-OS in i.MX8ULP. The ELE driver in OPTEE, is disabled for i.MX8ULP.
Moreover, there is CAAM in i.MX8ULP, which is used for security services, in OPTEE-OS.
>> Q2. How is the secure and non-secure world talk to the ELE if there is only
>> one MU?
>> A2. From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for
>> each world - Linux(one or more) and OP-TEE OS (one or more). Has updated
>> the commit message of 3/7.
> Does apply to the i.MX8ULP SoC as well?
No. Since there is no trust-MU for OPTEE-OS, on i.MX8ULP, to communicate with ELE.
> The NXP name scheme isn't very easy to follow.
>> Q3. How exactly do the eFuse write access after the device was locked down,
>> will be provided with single path; for the following case?
>> - For a verified boot setup, you need to burn an eFuse at some point,
>> to tell the bootROM to boot only correct verified firmware images.
>> - After this lockdown, it's no longer possible to burn eFuses from the
>> REE, while the production line setup still requires the support.
>> A3. OP-TEE OS supports read fuses, currently as part of our quarterly release.
>> Write fuse will be in coming release. Please note that the current patch-
>> set does not contain any read/write eFuse feature.
> But one of your patches is mention it, right? So there will be still two
> paths.
Due to lack of trusted-mu, there is no way to read/write fuse on i.MX8ULP, from OPTEE-OS.
For current patch-set, it is the single path.
> Also according your IOCTL docuementation you want to expose the whole
> device to the user-space?
> | What: /dev/<se>_mu[0-9]+_ch[0-9]+
> | Date: Mar 2025
> | KernelVersion: 6.8
> | Contact: linux-imx@nxp.com, pankaj.gupta@nxp.com
> | Description:
> | NXP offers multiple hardware IP(s) for secure enclaves like EdgeLock-
> | Enclave(ELE), SECO. The character device file descriptors
> | /dev/<se>_mu*_ch* are the interface between userspace NXP's secure-
> | enclave shared library and the kernel driver.
> |
> | The ioctl(2)-based ABI is defined and documented in
> | [include]<linux/firmware/imx/ele_mu_ioctl.h>.
> | ioctl(s) are used primarily for:
> | - shared memory management
> | - allocation of I/O buffers
> | - getting mu info
> | - setting a dev-ctx as receiver to receive all the commands from FW
> | - getting SoC info
> | - send command and receive command response
^
> This is a rather uncommon approach. The kernel has interfaces to
> abstract hardware. You completely bypass this if you expose everything
> to the userspace.
It is in-correct.
Not everything, just exposed file-operation. and ioctl(s) for DMA(eable) buffer allocation from reserved lower memory region.
Things managed by Kernel:
* Send/receive path to ELE, is managed by Kernel.
* Receive/send patch to the ELE's slave NVM-manager, is managed by kernel.
* Low power management handled by kernel driver. In case of low-power state, ELE driver re-init the V2X IP as part of resume.
* Other kernel management layers like NVMEM, kernel HWRNG, will use the api(s) exposed by this driver.
* Loading the runtime FW.
>
>> Q4. What is the ELE behavior if the secure-world stresses the ELE? Is there
>> a MU priority so the normal-world MU may get blocked (never addressed)
>> or are both MUs scheduled in round-robin?
>> A4. ELE will pick the message from Both MU(s), based on FIFO.
> This doesn't answer my question. How gets the FIFO filled? If the one of
> both worlds aways keep the MU busy?
If both the world is keeping the MU busy. ELE will pick the first incoming message, let's say on MU#1,
While acknowledge and queueing the incoming message on the other MU#2, to be picked once
the handling of the current message at hand is completed. Despite the MU#1, is bombarded
With next message, but it will process the message from MU#2, while acking the incoming message
from MU#1. And add it to its queue. This way FIFO is maintained by ELE.
>> Q5. Why ELE performance matters?
>> - On i.MX8M, which uses the CAAM (the ELE predecessor), It can be
>> verified that the ARMv8 CE are much faster than the crypto-engine itself.
>> Therefore the CAAM is mostly unused.
>> A5. User looks for both type of implementation based on their usecase:
>> - Certain users still offload to CAAM, to save their ARM CPU cycles for
>> other priority tasks.
> I have never seen such designs but okay.
I assure you, there are several such cases with our system-engineering team.
>> - While certain customer choose ARM-CE for the crypto offloads for better
>> performance.
>> As far as ELE is concerned, it is not a crypto accelerator like CAAM.
>> Performance hungry crypto-ops are not recommended to be offloaded to ELE.
> I don't get this point. So NXP doesn't recommend to use the ELE for
> crypt-ops?
NXP does not recommend to offload the Crypto-Op to ELE, for performance cases.
>> Q6. For the IOT-cases where real-time encrypted feed from sensors, will take
>> latency hit, Does the ELE support inline en-/decryption?
>> A6. Yes, ELE support Inline Encryption Engine (IEE), starting i.MX95 onwards.
> May I ask, how is this connected and which interfaces are connected to
> the IEE? I would have checked it by myself but unfortunately NXP doesn't
> provide a TRM for the i.MX95 yet.
We can discuss this in greater depth on one-one email, where I will touch upon the IEE and its interfaces.
But, like to inform that there is not IEE on i.MX8ULP or even on i.Mx93.
>> Marco's Suggestions/NXP response:
>> ================================
>> S1. Below listed ELE access requirements, can be done from OP-TEE OS in all
>> the Life-Cycle states. then Why to use Linux?
>> - eFuse access (done via OP-TEE OS i.MX specific PTA): OTP eFuse R/W access
>> after doing the LOCK_DOWN fuse is no longer possible without OP-TEE OS. This
>> involves general purpose (GP) eFuses too.
>> - ELE ping every 1 day (kernel SMC WDG driver, OP-TEE OS wd driver).
>> - HW-RNG (kernel HWRNG driver + OP-TEE OS HWRNG PTA).
>> R1. There are i.MX9* users, that are not using OP-TEE OS, but still want
>> to use ELE features from Linux. So, these users are requesting for this
>> driver in Linux.
> Which ELE features?
All the features from Linux, when OPTEE-OS is not present like:
* Read/write efuses. (eg NVMEM Kernel driver). Where there is no requirement to chenge the eFuse, during SoC in provision lifecycle.
* Low power management at Linux driver.
* Linux HWRNG.
* Loading the secondary runtime fw.
>> As suggested by you, writing to eFuse after life-cycle closed state, the
>> driver in OP-TEE OS is needed.
>> Though there are other OP-TEE OS features too, that needs to be offloaded
>> to HSM, for security reasons, like:
>> - Hardware Unique Key(HUK) getting generated.
>> - OP-TEE OS's ASLR seed generation.
> We're talking about features the normal world wants to have access too,
> since you said ".. but still want to use ELE feature from Linux ..". The
> HUK and the TEE ASLR seed is clearly not something Linux wants to have
> access too.
You misunderstood my point. I was stressing that there is a need for two paths,
each from Linux and OPTEE-OS, in order to expose different feature-set required
by respective worlds, where 1 or 2 overlaps, while maximum are utilized by respective
worlds.
>> S2. Having one implementation is beneficial in the following ways:
>> - Multiple paths also requires more maintain- and testing effort.
>> - FW files with having +1 FW for the new i.MX9*, where there are plenty
>> already eg.: bootloader, TF-A, ele-fw, scu-fw (i.MX95), increases the
>> maintenance on both the paths.
>> - TEE code could be reused by other OSes.
>> - TEE is used anyway for new projects due to CRA and friends
>> R2. As conveyed in R1, there are Linux only users, that are dependent on SE
>> Linux kernel driver.
> What difference does it make if these Linux-only users get the ELE
> access via OP-TEE? It's just one binary more.
If the User does not choose to include optional OPTEE-OS, then ELE access
must be from Linux driver.
>> S3. Having one implementation is beneficial in the following ways:
>> - Adding the support for it to OP-TEE OS do not requires ELE-FW.
> I never said that this requires no ELE FW! I said it requires no ELE-FW
> update! Was the update already rolled out?
Yes, the updated FW is already release part of LF Q3 released on September 30, 2025.
It is not released as part any open repo.
>> - Concurrent access handling is done by the TEE core.
>> R3. As already mentioned that ELE FW fix is available, for concurrent access.
>> Please note that FW fix is not required for the current patch-set.
> Can you provide us a link to the fix please? The fix should fix the
> concurrent normal-world <-> secure-world MU access issue. Why is this
> fix not required if I have a running OP-TEE?
The fix is very much required to run concurrent access for i.XM93 and onwards.
But not for i.MX8ULP and current patch-set is based on i.MX8ULP.
>> S4. This series causes more confusions till the ELE FW fix is available to
>> allow concurrent access to ELE from both the worlds.
>> R4. FW fix is already available, and concurrent access is enabled by default
>> in LF Q3'25, release. Please note that FW fix is not required for the
>> current patch-set.
> Please provide a link to the new FW and why is the fix nor required for
> this patchset?
Again. The fix is very much required to run concurrent access for i.XM93 and onwards.
But not for i.MX8ULP and current patch-set is based on i.MX8ULP.
>> S5. Suggesting to add the OP-TEE OS support for the required features e.g. eFuses,
>> watchdog, HWRNG. The whole Linux part is mostly in place.
>> R5. Yes, the secure world features like eFuse read/write will be added
>> to OP-TEE OS. Please note that this patch-set does not contain any read/write
>> eFuse feature.
> I see, instead it expose the whole ELE to the userspace if I got it
> correct according to your IOCTL documentation. This would be even worse.
No, it is not a correct interpretation. As mentioned above, ELE driver abstract
all the hw interaction to have easy and simple file bases operations.
> Regards,
> Marco
Regards,
Pankaj
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [EXT] Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-10-27 6:43 ` [EXT] " Pankaj Gupta
@ 2025-11-03 19:08 ` Marco Felsch
2025-11-07 6:57 ` Pankaj Gupta
0 siblings, 1 reply; 17+ messages in thread
From: Marco Felsch @ 2025-11-03 19:08 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-doc@vger.kernel.org, Frank Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
On 25-10-27, Pankaj Gupta wrote:
> On 25-09-27, Pankaj Gupta wrote:
> >> Highlight:
> >>
> >> There are long discussion at V18 with Marco Felsch.
> >> https://lore.kernel.org/imx/AM9PR04MB8604F5A7DD8B1E41FDAD09039501A@AM9PR04MB
> >> 8604.eurprd04.prod.outlook.com/
> >>
> >> The key point is about using OP-TEE OS.
> >>
> >> Marco's questions:
> >> =================
> >> Q1. Both MU(s) from each world - Secure & Non-secure, cannot be used
> >> simultaneously. Why?
> >> A1. ELE FW fix is available, where concurrent access to ELE from both the
> >> world is working. This fix is not required for the current patch-set for
> >> i.MX8ULP.
> > According https://github.com/OP-TEE/optee_os/pull/7268/commits/83b516edc0270ca8300ce524a0c3d560e67a0f48#r1955899462
> > there is no fix yet. Can you please point me to the fixed version?
>
> It is not yet up-streamed to OPTEE-OS repo.
My intention of adding the above OP-TEE discussion link was to point out
that an ELE-FW bug exists which needs to be fixed.
> Fix version is part of NXP LF Q3 released on 30 September.
> Commit can be found on this URL: https://github.com/nxp-imx/imx-optee-os/commits/lf-6.12.34_2.1.0/.
I assume you meant the following commit:
- https://github.com/nxp-imx/imx-optee-os/commit/039f15017cea38c401f908e0e1662ba8806ed4e3
This adapts the timeout value to 100ms and seems more like an
workaround.
However, can NXP confirm that the ELE concurrent access is possible
without a previous ELE FW update?
> One more fix is coming in LF Q4. After that, these patches will
> up-streamed to OP-TEE-OS.
>
> Then you will be able locate it in OPTEE-OS git repo.
Thanks for the sharing the links :)
> Since the current Patch-set is for i.MX8ULP, where concurrent access
> from both the world is not possible.
> In context to i.MX93, for OPTEE-OS patches, request you to please
> discuss in OPTEE community. Not here.
Sure, as said above, my intention was to point out that concurrent
access is not possible with the current ELE-FW. At least my knowledge
was that it was/is a ELE FW issue and not an OP-TEE issue.
> > Also, can you please outline why the fix is not required for i.MX8ULP?
> > Unfortunately I can't remember.
>
> There is no Trust-MU for OPTEE-OS in i.MX8ULP. The ELE driver in
> OPTEE, is disabled for i.MX8ULP.
Hm.. I thought there will be always two communication MUs one for the
secure-world and one for the non-secure world? Or what did you mean by:
"""
From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for each
world - Linux(one or more) and OPTEE-OS (one or more).
"""
(ref.:https://lore.kernel.org/all/AM9PR04MB8604C05882605EDB4913DA089549A@AM9PR04MB8604.eurprd04.prod.outlook.com/)
Does this mean that all i.MX9x, i.MX10x and so on do have the the
secure and non-secure MU setup? Or is it based on the SoC release date?
Because regarding the datasheet the i.MX8ULP is newer than the i.MX93,
therefore I assumed that the i.MX8ULP has two MUs as well.
I checked the the NXP OP-TEE source code and found the following commit:
8<----------------
commit 44388d37e68000ee50a9b1d656e0a60ae6614977
Author: Sahil Malhotra <sahil.malhotra@nxp.com>
Date: Tue Apr 1 20:04:44 2025 +0200
core: imx: disable ELE on i.MX8ULP by default
On i.MX8ULP, there is only one MU to communicate with ELE,
which cannot be dedicated on OP-TEE side all the time.
There may be ELE services running on Linux side, which can
cause conflict with OP-TEE, So disabling ELE by default.
Moreover i.MX8ULP also has CAAM, so HUK and Random number
are coming from CAAM.
Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
8<----------------
So it's possible to configure the XRDC (configured in the TF-A) in a way
to map the ELE access to the secure world. If I got the TF-A and OP-TEE
commits right.
To me this sound more like a NXP design decision to move the ELE to the
non-secure and the CAAM to the secure world.
> Moreover, there is CAAM in i.MX8ULP, which is used for security
> services, in OPTEE-OS.
i.MX8ULP is getting really interesting, though.
May I ask what RoT is used by this SoC if there are two?
> >> Q2. How is the secure and non-secure world talk to the ELE if there is only
> >> one MU?
> >> A2. From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for
> >> each world - Linux(one or more) and OP-TEE OS (one or more). Has updated
> >> the commit message of 3/7.
>
> > Does apply to the i.MX8ULP SoC as well?
>
> No. Since there is no trust-MU for OPTEE-OS, on i.MX8ULP, to
> communicate with ELE.
As said above it would be possible to move the ELE communication to the
secure world.
> > The NXP name scheme isn't very easy to follow.
>
> >> Q3. How exactly do the eFuse write access after the device was locked down,
> >> will be provided with single path; for the following case?
> >> - For a verified boot setup, you need to burn an eFuse at some point,
> >> to tell the bootROM to boot only correct verified firmware images.
> >> - After this lockdown, it's no longer possible to burn eFuses from the
> >> REE, while the production line setup still requires the support.
> >> A3. OP-TEE OS supports read fuses, currently as part of our quarterly release.
> >> Write fuse will be in coming release. Please note that the current patch-
> >> set does not contain any read/write eFuse feature.
>
> > But one of your patches is mention it, right? So there will be still two
> > paths.
> Due to lack of trusted-mu, there is no way to read/write fuse on i.MX8ULP, from OPTEE-OS.
> For current patch-set, it is the single path.
How does the i.MX8ULP fuse flow work, after the LOCK_DOWN fuse is blown?
This was one of my main concers why having OP-TEE required in the first
place, because the i.MX93 requires the that the fuse-request comes from
the secure-world if the device is in LOCK_DOWN state.
Is this also the case for the i.MX8ULP?
> > Also according your IOCTL docuementation you want to expose the whole
> > device to the user-space?
>
> > | What: /dev/<se>_mu[0-9]+_ch[0-9]+
> > | Date: Mar 2025
> > | KernelVersion: 6.8
> > | Contact: linux-imx@nxp.com, pankaj.gupta@nxp.com
> > | Description:
> > | NXP offers multiple hardware IP(s) for secure enclaves like EdgeLock-
> > | Enclave(ELE), SECO. The character device file descriptors
> > | /dev/<se>_mu*_ch* are the interface between userspace NXP's secure-
> > | enclave shared library and the kernel driver.
> > |
> > | The ioctl(2)-based ABI is defined and documented in
> > | [include]<linux/firmware/imx/ele_mu_ioctl.h>.
> > | ioctl(s) are used primarily for:
> > | - shared memory management
> > | - allocation of I/O buffers
> > | - getting mu info
> > | - setting a dev-ctx as receiver to receive all the commands from FW
> > | - getting SoC info
> > | - send command and receive command response
> ^
> > This is a rather uncommon approach. The kernel has interfaces to
> > abstract hardware. You completely bypass this if you expose everything
> > to the userspace.
>
> It is in-correct.
> Not everything, just exposed file-operation. and ioctl(s) for DMA(eable) buffer allocation from reserved lower memory region.
> Things managed by Kernel:
> * Send/receive path to ELE, is managed by Kernel.
> * Receive/send patch to the ELE's slave NVM-manager, is managed by kernel.
> * Low power management handled by kernel driver. In case of low-power state, ELE driver re-init the V2X IP as part of resume.
> * Other kernel management layers like NVMEM, kernel HWRNG, will use the api(s) exposed by this driver.
But you also expose an uAPI which allows the user to bypass everything
via sending arbitrary commands, right?
> * Loading the runtime FW.
> >
> >> Q4. What is the ELE behavior if the secure-world stresses the ELE? Is there
> >> a MU priority so the normal-world MU may get blocked (never addressed)
> >> or are both MUs scheduled in round-robin?
> >> A4. ELE will pick the message from Both MU(s), based on FIFO.
>
> > This doesn't answer my question. How gets the FIFO filled? If the one of
> > both worlds aways keep the MU busy?
>
> If both the world is keeping the MU busy. ELE will pick the first incoming message, let's say on MU#1,
> While acknowledge and queueing the incoming message on the other MU#2, to be picked once
> the handling of the current message at hand is completed. Despite the MU#1, is bombarded
> With next message, but it will process the message from MU#2, while acking the incoming message
> from MU#1. And add it to its queue. This way FIFO is maintained by ELE.
:) Thanks for the explanation.
> >> Q5. Why ELE performance matters?
> >> - On i.MX8M, which uses the CAAM (the ELE predecessor), It can be
> >> verified that the ARMv8 CE are much faster than the crypto-engine itself.
> >> Therefore the CAAM is mostly unused.
> >> A5. User looks for both type of implementation based on their usecase:
> >> - Certain users still offload to CAAM, to save their ARM CPU cycles for
> >> other priority tasks.
>
> > I have never seen such designs but okay.
> I assure you, there are several such cases with our system-engineering team.
>
> >> - While certain customer choose ARM-CE for the crypto offloads for better
> >> performance.
> >> As far as ELE is concerned, it is not a crypto accelerator like CAAM.
> >> Performance hungry crypto-ops are not recommended to be offloaded to ELE.
>
> > I don't get this point. So NXP doesn't recommend to use the ELE for
> > crypt-ops?
> NXP does not recommend to offload the Crypto-Op to ELE, for performance cases.
Good to know, thanks.
> >> Q6. For the IOT-cases where real-time encrypted feed from sensors, will take
> >> latency hit, Does the ELE support inline en-/decryption?
> >> A6. Yes, ELE support Inline Encryption Engine (IEE), starting i.MX95 onwards.
>
> > May I ask, how is this connected and which interfaces are connected to
> > the IEE? I would have checked it by myself but unfortunately NXP doesn't
> > provide a TRM for the i.MX95 yet.
> We can discuss this in greater depth on one-one email, where I will touch upon the IEE and its interfaces.
> But, like to inform that there is not IEE on i.MX8ULP or even on i.Mx93.
Sure, thanks.
> >> Marco's Suggestions/NXP response:
> >> ================================
> >> S1. Below listed ELE access requirements, can be done from OP-TEE OS in all
> >> the Life-Cycle states. then Why to use Linux?
> >> - eFuse access (done via OP-TEE OS i.MX specific PTA): OTP eFuse R/W access
> >> after doing the LOCK_DOWN fuse is no longer possible without OP-TEE OS. This
> >> involves general purpose (GP) eFuses too.
> >> - ELE ping every 1 day (kernel SMC WDG driver, OP-TEE OS wd driver).
> >> - HW-RNG (kernel HWRNG driver + OP-TEE OS HWRNG PTA).
> >> R1. There are i.MX9* users, that are not using OP-TEE OS, but still want
> >> to use ELE features from Linux. So, these users are requesting for this
> >> driver in Linux.
>
> > Which ELE features?
> All the features from Linux, when OPTEE-OS is not present like:
> * Read/write efuses. (eg NVMEM Kernel driver). Where there is no requirement to chenge the eFuse, during SoC in provision lifecycle.
Some features require the device to be in LOCK_DOWN mode, which requires
secure-world eFuse write path only afterwards. But it seems like NXP
really wants to maintain two write paths.
> * Low power management at Linux driver.
The power-modes are selected via the ELE?
> * Linux HWRNG.
> * Loading the secondary runtime fw.
What is a secondary runtime-fw?
> >> As suggested by you, writing to eFuse after life-cycle closed state, the
> >> driver in OP-TEE OS is needed.
> >> Though there are other OP-TEE OS features too, that needs to be offloaded
> >> to HSM, for security reasons, like:
> >> - Hardware Unique Key(HUK) getting generated.
> >> - OP-TEE OS's ASLR seed generation.
>
> > We're talking about features the normal world wants to have access too,
> > since you said ".. but still want to use ELE feature from Linux ..". The
> > HUK and the TEE ASLR seed is clearly not something Linux wants to have
> > access too.
> You misunderstood my point. I was stressing that there is a need for two paths,
> each from Linux and OPTEE-OS, in order to expose different feature-set required
> by respective worlds, where 1 or 2 overlaps, while maximum are utilized by respective
> worlds.
>
> >> S2. Having one implementation is beneficial in the following ways:
> >> - Multiple paths also requires more maintain- and testing effort.
> >> - FW files with having +1 FW for the new i.MX9*, where there are plenty
> >> already eg.: bootloader, TF-A, ele-fw, scu-fw (i.MX95), increases the
> >> maintenance on both the paths.
> >> - TEE code could be reused by other OSes.
> >> - TEE is used anyway for new projects due to CRA and friends
> >> R2. As conveyed in R1, there are Linux only users, that are dependent on SE
> >> Linux kernel driver.
>
> > What difference does it make if these Linux-only users get the ELE
> > access via OP-TEE? It's just one binary more.
> If the User does not choose to include optional OPTEE-OS, then ELE access
> must be from Linux driver.
Okay, I think we're going in circles here.
> >> S3. Having one implementation is beneficial in the following ways:
> >> - Adding the support for it to OP-TEE OS do not requires ELE-FW.
>
> > I never said that this requires no ELE FW! I said it requires no ELE-FW
> > update! Was the update already rolled out?
> Yes, the updated FW is already release part of LF Q3 released on September 30, 2025.
> It is not released as part any open repo.
So there is no ELE-FW update required to have both worlds running
concurrently.
> >> - Concurrent access handling is done by the TEE core.
> >> R3. As already mentioned that ELE FW fix is available, for concurrent access.
> >> Please note that FW fix is not required for the current patch-set.
>
> > Can you provide us a link to the fix please? The fix should fix the
> > concurrent normal-world <-> secure-world MU access issue. Why is this
> > fix not required if I have a running OP-TEE?
> The fix is very much required to run concurrent access for i.XM93 and onwards.
> But not for i.MX8ULP and current patch-set is based on i.MX8ULP.
I see, the i.MX8ULP has only on MU. As said above my assumption was that
all ELE SoCs do have at least 2-MUs.
> >> S4. This series causes more confusions till the ELE FW fix is available to
> >> allow concurrent access to ELE from both the worlds.
> >> R4. FW fix is already available, and concurrent access is enabled by default
> >> in LF Q3'25, release. Please note that FW fix is not required for the
> >> current patch-set.
>
> > Please provide a link to the new FW and why is the fix nor required for
> > this patchset?
> Again. The fix is very much required to run concurrent access for i.XM93 and onwards.
> But not for i.MX8ULP and current patch-set is based on i.MX8ULP.
My bad, as said: my assumption was that all ELE SoCs do have at least
two MUs.
> >> S5. Suggesting to add the OP-TEE OS support for the required features e.g. eFuses,
> >> watchdog, HWRNG. The whole Linux part is mostly in place.
> >> R5. Yes, the secure world features like eFuse read/write will be added
> >> to OP-TEE OS. Please note that this patch-set does not contain any read/write
> >> eFuse feature.
>
> > I see, instead it expose the whole ELE to the userspace if I got it
> > correct according to your IOCTL documentation. This would be even worse.
> No, it is not a correct interpretation. As mentioned above, ELE driver abstract
> all the hw interaction to have easy and simple file bases operations.
But still, the user can send arbitrary commands to the ELE right?
To conclude this longly discussion:
My main concern was the concurrent access for the 2-MUs cases. This can
be closed, as it turns out NXP fixed/workarounded this by increasing the
ELE communication timeout to 100ms.
I still have mixed feeling about the fusing (including the 1-MU case),
since it requires a secure-world OS in place once the LOCK_DOWN fuse was
burned. It's fine by me if NXP wants to have and wants to maintain a
multi-path here.
Last but least, the uAPI which can be used to send arbitrary ELE
commands seems unusual. But I don't know how secure-enclaves are
abstracted within the kernel, so these are just my two cents.
I'm looking forward to the maintainers feedback.
Regards,
Marco
>
> > Regards,
> > Marco
>
> Regards,
> Pankaj
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply [flat|nested] 17+ messages in thread* RE: [EXT] Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-11-03 19:08 ` Marco Felsch
@ 2025-11-07 6:57 ` Pankaj Gupta
2025-11-11 13:14 ` Marco Felsch
0 siblings, 1 reply; 17+ messages in thread
From: Pankaj Gupta @ 2025-11-07 6:57 UTC (permalink / raw)
To: Marco Felsch
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-doc@vger.kernel.org, Frank Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
>> On 25-10-27, Pankaj Gupta wrote:
>>> On 25-09-27, Pankaj Gupta wrote:
>> > >> Highlight:
>> > >>
>> > >> There are long discussion at V18 with Marco Felsch.
>> > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
>> > >> 2Fl
>> > >>
>> ore.kernel.org%2Fimx%2FAM9PR04MB8604F5A7DD8B1E41FDAD09039501
>> A%40AM9
>> > >>
>> PR04MB&data=05%7C02%7Cpankaj.gupta%40nxp.com%7C853f73b919714
>> 8e3c4ea
>> > >>
>> 08de1b0c6148%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
>> 38977937
>> > >>
>> 182676166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
>> IlYiOiIwL
>> > >>
>> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
>> %7C%
>> > >>
>> 7C%7C&sdata=2LXQbwdgb4Sb3PaYMUhn3gmSaJZW3%2FNXAJOX6d%2Fh%
>> 2BwI%3D&re
>> > >> served=0
>> > >> 8604.eurprd04.prod.outlook.com/
>> > >>
>> > >> The key point is about using OP-TEE OS.
>> > >>
>> > >> Marco's questions:
>> > >> =================
>> > >> Q1. Both MU(s) from each world - Secure & Non-secure, cannot be used
>> > >> simultaneously. Why?
>> > >> A1. ELE FW fix is available, where concurrent access to ELE from both the
>> > >> world is working. This fix is not required for the current patch-set for
>> > >> i.MX8ULP.
>> > > According
>> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> > > Fgi
>> > > thub.com%2FOP-
>> TEE%2Foptee_os%2Fpull%2F7268%2Fcommits%2F83b516edc0270
>> > >
>> ca8300ce524a0c3d560e67a0f48%23r1955899462&data=05%7C02%7Cpan
>> kaj.gupt
>> > >
>> a%40nxp.com%7C853f73b9197148e3c4ea08de1b0c6148%7C686ea1d3bc2
>> b4c6fa92
>> > >
>> cd99c5c301635%7C0%7C0%7C638977937182705340%7CUnknown%7CT
>> WFpbGZsb3d8e
>> > >
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
>> oiT
>> > >
> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=k30VGVc%2BEYsHw3
> QOABgFZw6
> > > v%2F5oSZx7%2FekHCDaZjbH8%3D&reserved=0
> > > there is no fix yet. Can you please point me to the fixed version?
> >
> > It is not yet up-streamed to OPTEE-OS repo.
>
> My intention of adding the above OP-TEE discussion link was to point
> out that an ELE-FW bug exists which needs to be fixed.
>
> > Fix version is part of NXP LF Q3 released on 30 September.
> > Commit can be found on this URL:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> u
> b.com%2Fnxp-imx%2Fimx-optee-os%2Fcommits%2Flf-
> 6.12.34_2.1.0%2F&data=05%7C02%7Cpankaj.gupta%40nxp.com%7C853f7
> 3b9197148e3c4ea08de1b0c6148%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C638977937182721931%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U6Rh%2Be1CTBdJ
> PGGyfm5hF4mqylkBcSQp6KNzE9cL%2FUo%3D&reserved=0.
>
> I assume you meant the following commit:
> -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> u
> b.com%2Fnxp-imx%2Fimx-optee-
> os%2Fcommit%2F039f15017cea38c401f908e0e1662ba8806ed4e3&data=0
> 5%7C02%7Cpankaj.gupta%40nxp.com%7C853f73b9197148e3c4ea08de1b
> 0c6148%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6389779
> 37182737561%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW
> UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> %3D%7C0%7C%7C%7C&sdata=5mxtHM9Fy0i94lRNn1itWJcTWU4Ca%2F0ZR
> ZUDRTl9WxQ%3D&reserved=0
>
> This adapts the timeout value to 100ms and seems more like an workaround.
>
There are additional fixes in OPTEE-OS, that will be part of LF Q4'25.
> However, can NXP confirm that the ELE concurrent access is possible
> without a previous ELE FW update?
Fix in the ELE FW, released as part of LF Q3 2025, is a must to include. OPTEE fixes are also needed.
OPTEE fixes will be up-streamed soon.
>
> > One more fix is coming in LF Q4. After that, these patches will
> > up-streamed to OP-TEE-OS.
> >
> > Then you will be able locate it in OPTEE-OS git repo.
>
> Thanks for the sharing the links :)
>
> > Since the current Patch-set is for i.MX8ULP, where concurrent access
> > from both the world is not possible.
>
> > In context to i.MX93, for OPTEE-OS patches, request you to please
> > discuss in OPTEE community. Not here.
>
> Sure, as said above, my intention was to point out that concurrent
> access is not possible with the current ELE-FW. At least my knowledge
> was that it was/is a ELE FW issue and not an OP-TEE issue.
>
> > > Also, can you please outline why the fix is not required for i.MX8ULP?
> > > Unfortunately I can't remember.
> >
> > There is no Trust-MU for OPTEE-OS in i.MX8ULP. The ELE driver in
> > OPTEE, is disabled for i.MX8ULP.
>
> Hm.. I thought there will be always two communication MUs one for the
> secure-world and one for the non-secure world? Or what did you mean by:
>
> """
> From i.MX9x & onwards, SoC(s) has at least one dedicated ELE MU(s) for
> each world - Linux(one or more) and OPTEE-OS (one or more).
> """
>
> (ref.:https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fl ore.kernel.org%2Fall%2FAM9PR04MB8604C05882605EDB4913DA089549A
> %40AM9PR04MB8604.eurprd04.prod.outlook.com%2F&data=05%7C02%7
> Cpankaj.gupta%40nxp.com%7C853f73b9197148e3c4ea08de1b0c6148%7C
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6389779371827527
> 25%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%
> 7C%7C%7C&sdata=PhXXih6UnalGUPveMZPaS2EVAd2SMR%2FyblcjyuHRUrw
> %3D&reserved=0)
>
> Does this mean that all i.MX9x, i.MX10x and so on do have the the
> secure and non-secure MU setup? Or is it based on the SoC release date?
> Because regarding the datasheet the i.MX8ULP is newer than the i.MX93,
> therefore I assumed that the i.MX8ULP has two MUs as well.
From i.MX93 and onward, there is only one RoT. Hence , it is designed to have dedicated MU for each world.
>
> I checked the the NXP OP-TEE source code and found the following commit:
>
> 8<----------------
> commit 44388d37e68000ee50a9b1d656e0a60ae6614977
> Author: Sahil Malhotra <sahil.malhotra@nxp.com>
> Date: Tue Apr 1 20:04:44 2025 +0200
>
> core: imx: disable ELE on i.MX8ULP by default
>
> On i.MX8ULP, there is only one MU to communicate with ELE,
> which cannot be dedicated on OP-TEE side all the time.
> There may be ELE services running on Linux side, which can
> cause conflict with OP-TEE, So disabling ELE by default.
> Moreover i.MX8ULP also has CAAM, so HUK and Random number
> are coming from CAAM.
>
> Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
> 8<----------------
>
> So it's possible to configure the XRDC (configured in the TF-A) in a
> way to map the ELE access to the secure world. If I got the TF-A and OP-TEE commits right.
>
> To me this sound more like a NXP design decision to move the ELE to
> the non- secure and the CAAM to the secure world.
>
As per the i.MX8ULP boot-up sequence and ELE's initial role in boot-up, with CAAM co-exists, ELE is logical to be with Linux.
Another point here that CAAM has 4 JR(s) and hence CAAM can be shared between Linux and OPTEE-OS.
> > Moreover, there is CAAM in i.MX8ULP, which is used for security
> > services, in OPTEE-OS.
>
> i.MX8ULP is getting really interesting, though.
>
> May I ask what RoT is used by this SoC if there are two?
>
ELE is Root of Trust during secure boot.
For OPTEE-OS, CAAM is RoT.
>
> > >> Q2. How is the secure and non-secure world talk to the ELE if there is only
> > >> one MU?
> > >> A2. From i.MX9x & onwards, SoC(s) has at least one dedicated ELE
> > >> MU(s)
> for
> > >> each world - Linux(one or more) and OP-TEE OS (one or more).
> > >> Has
> updated
> > >> the commit message of 3/7.
> >
> > > Does apply to the i.MX8ULP SoC as well?
> >
> > No. Since there is no trust-MU for OPTEE-OS, on i.MX8ULP, to
> > communicate with ELE.
>
> As said above it would be possible to move the ELE communication to
> the secure world.
>
> > > The NXP name scheme isn't very easy to follow.
> >
> > >> Q3. How exactly do the eFuse write access after the device was
> > >> locked
> down,
> > >> will be provided with single path; for the following case?
> > >> - For a verified boot setup, you need to burn an eFuse at some point,
> > >> to tell the bootROM to boot only correct verified firmware images.
> > >> - After this lockdown, it's no longer possible to burn eFuses from the
> > >> REE, while the production line setup still requires the support.
> > >> A3. OP-TEE OS supports read fuses, currently as part of our
> > >> quarterly
> release.
> > >> Write fuse will be in coming release. Please note that the current patch-
> > >> set does not contain any read/write eFuse feature.
> >
> > > But one of your patches is mention it, right? So there will be
> > > still two paths.
> > Due to lack of trusted-mu, there is no way to read/write fuse on
> > i.MX8ULP,
> from OPTEE-OS.
> > For current patch-set, it is the single path.
>
> How does the i.MX8ULP fuse flow work, after the LOCK_DOWN fuse is blown?
There is no such issue on i.MX8ULP
>
> This was one of my main concers why having OP-TEE required in the
> first place, because the i.MX93 requires the that the fuse-request
> comes from the secure-world if the device is in LOCK_DOWN state.
>
> Is this also the case for the i.MX8ULP?
>
No, this is not a valid case for i.MX8ULP.
> > > Also according your IOCTL docuementation you want to expose the
> > > whole device to the user-space?
> >
> > > | What: /dev/<se>_mu[0-9]+_ch[0-9]+
> > > | Date: Mar 2025
> > > | KernelVersion: 6.8
> > > | Contact: linux-imx@nxp.com, pankaj.gupta@nxp.com
> > > | Description:
> > > | NXP offers multiple hardware IP(s) for secure
> > > | enclaves like
> EdgeLock-
> > > | Enclave(ELE), SECO. The character device file descriptors
> > > | /dev/<se>_mu*_ch* are the interface between
> > > | userspace NXP's
> secure-
> > > | enclave shared library and the kernel driver.
> > > |
> > > | The ioctl(2)-based ABI is defined and documented in
> > > | [include]<linux/firmware/imx/ele_mu_ioctl.h>.
> > > | ioctl(s) are used primarily for:
> > > | - shared memory management
> > > | - allocation of I/O buffers
> > > | - getting mu info
> > > | - setting a dev-ctx as receiver to
> > > | receive all the commands
> from FW
> > > | - getting SoC info
> > > | - send command and receive command
> > > | response
> > ^
> > > This is a rather uncommon approach. The kernel has interfaces to
> > > abstract hardware. You completely bypass this if you expose
> > > everything to the userspace.
> >
> > It is in-correct.
> > Not everything, just exposed file-operation. and ioctl(s) for
> > DMA(eable)
> buffer allocation from reserved lower memory region.
> > Things managed by Kernel:
> > * Send/receive path to ELE, is managed by Kernel.
> > * Receive/send patch to the ELE's slave NVM-manager, is managed by kernel.
> > * Low power management handled by kernel driver. In case of
> > low-power
> state, ELE driver re-init the V2X IP as part of resume.
> > * Other kernel management layers like NVMEM, kernel HWRNG, will use
> > the
> api(s) exposed by this driver.
>
> But you also expose an uAPI which allows the user to bypass everything
> via sending arbitrary commands, right?
Yes. But it's not unusual at all. The pattern of userspace sending commands directly to the kernel, is quite common
>
> > * Loading the runtime FW.
> > >
> > >> Q4. What is the ELE behavior if the secure-world stresses the ELE? Is there
> > >> a MU priority so the normal-world MU may get blocked (never
> addressed)
> > >> or are both MUs scheduled in round-robin?
> > >> A4. ELE will pick the message from Both MU(s), based on FIFO.
> >
> > > This doesn't answer my question. How gets the FIFO filled? If the
> > > one of both worlds aways keep the MU busy?
> >
> > If both the world is keeping the MU busy. ELE will pick the first
> > incoming message, let's say on MU#1, While acknowledge and queueing
> > the incoming message on the other MU#2, to be picked once the
> > handling of the current message at hand is completed. Despite the
> > MU#1, is bombarded With next message, but it will process the
> > message from MU#2,
> while acking the incoming message from MU#1. And add it to its queue.
> This way FIFO is maintained by ELE.
>
> :) Thanks for the explanation.
>
> > >> Q5. Why ELE performance matters?
> > >> - On i.MX8M, which uses the CAAM (the ELE predecessor), It can be
> > >> verified that the ARMv8 CE are much faster than the
> > >> crypto-engine
> itself.
> > >> Therefore the CAAM is mostly unused.
> > >> A5. User looks for both type of implementation based on their usecase:
> > >> - Certain users still offload to CAAM, to save their ARM CPU cycles for
> > >> other priority tasks.
> >
> > > I have never seen such designs but okay.
> > I assure you, there are several such cases with our system-engineering team.
> >
> > >> - While certain customer choose ARM-CE for the crypto
> > >> offloads for
> better
> > >> performance.
> > >> As far as ELE is concerned, it is not a crypto accelerator like CAAM.
> > >> Performance hungry crypto-ops are not recommended to be
> > >> offloaded
> to ELE.
> >
> > > I don't get this point. So NXP doesn't recommend to use the ELE
> > > for crypt-ops?
> > NXP does not recommend to offload the Crypto-Op to ELE, for
> > performance
> cases.
>
> Good to know, thanks.
>
> > >> Q6. For the IOT-cases where real-time encrypted feed from
> > >> sensors, will
> take
> > >> latency hit, Does the ELE support inline en-/decryption?
> > >> A6. Yes, ELE support Inline Encryption Engine (IEE), starting
> > >> i.MX95
> onwards.
> >
> > > May I ask, how is this connected and which interfaces are
> > > connected to the IEE? I would have checked it by myself but
> > > unfortunately NXP doesn't provide a TRM for the i.MX95 yet.
> > We can discuss this in greater depth on one-one email, where I will
> > touch
> upon the IEE and its interfaces.
> > But, like to inform that there is not IEE on i.MX8ULP or even on i.Mx93.
>
> Sure, thanks.
>
> > >> Marco's Suggestions/NXP response:
> > >> ================================
> > >> S1. Below listed ELE access requirements, can be done from OP-TEE
> > >> OS in
> all
> > >> the Life-Cycle states. then Why to use Linux?
> > >> - eFuse access (done via OP-TEE OS i.MX specific PTA): OTP
> > >> eFuse R/W
> access
> > >> after doing the LOCK_DOWN fuse is no longer possible without
> > >> OP-TEE
> OS. This
> > >> involves general purpose (GP) eFuses too.
> > >> - ELE ping every 1 day (kernel SMC WDG driver, OP-TEE OS wd driver).
> > >> - HW-RNG (kernel HWRNG driver + OP-TEE OS HWRNG PTA).
> > >> R1. There are i.MX9* users, that are not using OP-TEE OS, but still want
> > >> to use ELE features from Linux. So, these users are requesting for this
> > >> driver in Linux.
> >
> > > Which ELE features?
> > All the features from Linux, when OPTEE-OS is not present like:
> > * Read/write efuses. (eg NVMEM Kernel driver). Where there is no
> requirement to chenge the eFuse, during SoC in provision lifecycle.
>
> Some features require the device to be in LOCK_DOWN mode, which
> requires secure-world eFuse write path only afterwards. But it seems
> like NXP really wants to maintain two write paths.
>
> > * Low power management at Linux driver.
>
> The power-modes are selected via the ELE?
Voltage regulation for i.MX93 in Linux kernel, is done by ELE.
During Linux suspend-resume, Secure-enclave (V2X on i.MX95) part of wake-up domain, will be managed by secure-enclaves(ELE) part of always-on domain.
>
> > * Linux HWRNG.
> > * Loading the secondary runtime fw.
>
> What is a secondary runtime-fw?
ELE FW size is larger than the size of ELE internal secure memory.
Hence FW is split into two.
Primary FW, is the FW, that enables features that helps for SoC boot-up.
Secondary runtime FW, is the FW, that enables features like HSM.
>
> > >> As suggested by you, writing to eFuse after life-cycle closed state, the
> > >> driver in OP-TEE OS is needed.
> > >> Though there are other OP-TEE OS features too, that needs to
> > >> be
> offloaded
> > >> to HSM, for security reasons, like:
> > >> - Hardware Unique Key(HUK) getting generated.
> > >> - OP-TEE OS's ASLR seed generation.
> >
> > > We're talking about features the normal world wants to have access
> > > too, since you said ".. but still want to use ELE feature from
> > > Linux ..". The HUK and the TEE ASLR seed is clearly not something
> > > Linux wants to have access too.
> > You misunderstood my point. I was stressing that there is a need for
> > two paths, each from Linux and OPTEE-OS, in order to expose
> > different feature-set required by respective worlds, where 1 or 2
> > overlaps, while maximum are utilized by respective worlds.
> >
> > >> S2. Having one implementation is beneficial in the following ways:
> > >> - Multiple paths also requires more maintain- and testing effort.
> > >> - FW files with having +1 FW for the new i.MX9*, where there are plenty
> > >> already eg.: bootloader, TF-A, ele-fw, scu-fw (i.MX95), increases the
> > >> maintenance on both the paths.
> > >> - TEE code could be reused by other OSes.
> > >> - TEE is used anyway for new projects due to CRA and friends
> > >> R2. As conveyed in R1, there are Linux only users, that are
> > >> dependent on
> SE
> > >> Linux kernel driver.
> >
> > > What difference does it make if these Linux-only users get the ELE
> > > access via OP-TEE? It's just one binary more.
> > If the User does not choose to include optional OPTEE-OS, then ELE
> > access must be from Linux driver.
>
> Okay, I think we're going in circles here.
>
> > >> S3. Having one implementation is beneficial in the following ways:
> > >> - Adding the support for it to OP-TEE OS do not requires ELE-FW.
> >
> > > I never said that this requires no ELE FW! I said it requires no
> > > ELE-FW update! Was the update already rolled out?
> > Yes, the updated FW is already release part of LF Q3 released on
> > September
> 30, 2025.
> > It is not released as part any open repo.
>
> So there is no ELE-FW update required to have both worlds running
> concurrently.
As mentioned below "But not for i.MX8ULP", concurrent access case is not a valid case for i.MX8ULP & current patch-set.
>
> > >> - Concurrent access handling is done by the TEE core.
> > >> R3. As already mentioned that ELE FW fix is available, for
> > >> concurrent
> access.
> > >> Please note that FW fix is not required for the current patch-set.
> >
> > > Can you provide us a link to the fix please? The fix should fix
> > > the concurrent normal-world <-> secure-world MU access issue. Why
> > > is this fix not required if I have a running OP-TEE?
> > The fix is very much required to run concurrent access for i.XM93
> > and
> onwards.
> > But not for i.MX8ULP and current patch-set is based on i.MX8ULP.
>
> I see, the i.MX8ULP has only on MU. As said above my assumption was
> that all ELE SoCs do have at least 2-MUs."
As mentioned above "But not for i.MX8ULP", concurrent access case is not a valid case for 8ULP & current patch-set.
>
> > >> S4. This series causes more confusions till the ELE FW fix is available to
> > >> allow concurrent access to ELE from both the worlds.
> > >> R4. FW fix is already available, and concurrent access is enabled by default
> > >> in LF Q3'25, release. Please note that FW fix is not required for the
> > >> current patch-set.
> >
> > > Please provide a link to the new FW and why is the fix nor
> > > required for this patchset?
> > Again. The fix is very much required to run concurrent access for
> > i.XM93 and
> onwards.
> > But not for i.MX8ULP and current patch-set is based on i.MX8ULP.
>
> My bad, as said: my assumption was that all ELE SoCs do have at least
> two MUs.
>
> > >> S5. Suggesting to add the OP-TEE OS support for the required
> > >> features
> e.g. eFuses,
> > >> watchdog, HWRNG. The whole Linux part is mostly in place.
> > >> R5. Yes, the secure world features like eFuse read/write will be added
> > >> to OP-TEE OS. Please note that this patch-set does not
> > >> contain any
> read/write
> > >> eFuse feature.
> >
> > > I see, instead it expose the whole ELE to the userspace if I got
> > > it correct according to your IOCTL documentation. This would be even worse.
> > No, it is not a correct interpretation. As mentioned above, ELE
> > driver abstract all the hw interaction to have easy and simple file bases operations.
>
> But still, the user can send arbitrary commands to the ELE right?
>
> To conclude this longly discussion:
>
> My main concern was the concurrent access for the 2-MUs cases. This
> can be closed, as it turns out NXP fixed/workarounded this by
> increasing the ELE communication timeout to 100ms.
>
This will be not only the fix. There are other fixes like atomic write to trusted-MU.
Let's discuss in OPTEE-forum.
> I still have mixed feeling about the fusing (including the 1-MU case),
> since it requires a secure-world OS in place once the LOCK_DOWN fuse was burned.
> It's fine by me if NXP wants to have and wants to maintain a multi-path here.
>
Write fuse API will be added, to allow writing fuses from secure world too.
> Last but least, the uAPI which can be used to send arbitrary ELE
> commands seems unusual. But I don't know how secure-enclaves are
> abstracted within the kernel, so these are just my two cents.
it's not unusual at all. The pattern of userspace sending commands directly to the kernel via a queue is quite common like:
GPUs: As you mentioned, userspace drivers (like those in Vulkan or CUDA) often build command buffers and submit them directly to the kernel or hardware.
Secure Enclaves: In systems like Intel SGX or AMD SEV, userspace applications interact with enclaves via ioctl or mmap interfaces, often sending structured commands or messages.
The uAPI (userspace API) for sending ELE (Enclave Lifecycle Engine?) commands likely follows this same model - abstracting the enclave as a device or subsystem and exposing a command queue or ioctl interface for userspace to interact with it.
>
> I'm looking forward to the maintainers feedback.
>
> Regards,
> Marco
>
>
>>
>>> Regards,
>>> Marco
>>
> > Regards,
>> Pankaj
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [EXT] Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-11-07 6:57 ` Pankaj Gupta
@ 2025-11-11 13:14 ` Marco Felsch
2025-11-12 11:38 ` Pankaj Gupta
0 siblings, 1 reply; 17+ messages in thread
From: Marco Felsch @ 2025-11-11 13:14 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-doc@vger.kernel.org, Frank Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
On 25-11-07, Pankaj Gupta wrote:
> >> On 25-10-27, Pankaj Gupta wrote:
> >>> On 25-09-27, Pankaj Gupta wrote:
...
> > > It is not yet up-streamed to OPTEE-OS repo.
> >
> > My intention of adding the above OP-TEE discussion link was to point
> > out that an ELE-FW bug exists which needs to be fixed.
...
> > This adapts the timeout value to 100ms and seems more like an workaround.
> >
> There are additional fixes in OPTEE-OS, that will be part of LF Q4'25.
Thanks for this info.
> > However, can NXP confirm that the ELE concurrent access is possible
> > without a previous ELE FW update?
>
> Fix in the ELE FW, released as part of LF Q3 2025, is a must to
> include. OPTEE fixes are also needed. OPTEE fixes will be up-streamed
> soon.
Okay, so there are ELE-FW fixes too, thanks.
...
> > Does this mean that all i.MX9x, i.MX10x and so on do have the the
> > secure and non-secure MU setup? Or is it based on the SoC release date?
> > Because regarding the datasheet the i.MX8ULP is newer than the i.MX93,
> > therefore I assumed that the i.MX8ULP has two MUs as well.
>
> From i.MX93 and onward, there is only one RoT. Hence , it is designed
> to have dedicated MU for each world.
Okay.
> > I checked the the NXP OP-TEE source code and found the following commit:
> >
> > 8<----------------
> > commit 44388d37e68000ee50a9b1d656e0a60ae6614977
> > Author: Sahil Malhotra <sahil.malhotra@nxp.com>
> > Date: Tue Apr 1 20:04:44 2025 +0200
> >
> > core: imx: disable ELE on i.MX8ULP by default
> >
> > On i.MX8ULP, there is only one MU to communicate with ELE,
> > which cannot be dedicated on OP-TEE side all the time.
> > There may be ELE services running on Linux side, which can
> > cause conflict with OP-TEE, So disabling ELE by default.
> > Moreover i.MX8ULP also has CAAM, so HUK and Random number
> > are coming from CAAM.
> >
> > Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
> > Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
> > 8<----------------
> >
> > So it's possible to configure the XRDC (configured in the TF-A) in a
> > way to map the ELE access to the secure world. If I got the TF-A and OP-TEE commits right.
> >
> > To me this sound more like a NXP design decision to move the ELE to
> > the non- secure and the CAAM to the secure world.
>
> As per the i.MX8ULP boot-up sequence and ELE's initial role in
> boot-up, with CAAM co-exists, ELE is logical to be with Linux.
>
> Another point here that CAAM has 4 JR(s) and hence CAAM can be shared
> between Linux and OPTEE-OS.
Please see my answer below where you explained the ELE functions.
...
> > i.MX8ULP is getting really interesting, though.
> >
> > May I ask what RoT is used by this SoC if there are two?
> >
> ELE is Root of Trust during secure boot.
> For OPTEE-OS, CAAM is RoT.
The i.MX8ULP is very interesting, since you also need to handle the
SoC secure-state twice, right? However, this topic alone is worth it a
standalone discussion thread, therefore no further comments.
...
> > How does the i.MX8ULP fuse flow work, after the LOCK_DOWN fuse is blown?
> There is no such issue on i.MX8ULP
> >
> > This was one of my main concers why having OP-TEE required in the
> > first place, because the i.MX93 requires the that the fuse-request
> > comes from the secure-world if the device is in LOCK_DOWN state.
> >
> > Is this also the case for the i.MX8ULP?
> >
>
> No, this is not a valid case for i.MX8ULP.
Thanks for the input.
> > > > Also according your IOCTL docuementation you want to expose the
> > > > whole device to the user-space?
> > >
> > > > | What: /dev/<se>_mu[0-9]+_ch[0-9]+
> > > > | Date: Mar 2025
> > > > | KernelVersion: 6.8
> > > > | Contact: linux-imx@nxp.com, pankaj.gupta@nxp.com
> > > > | Description:
> > > > | NXP offers multiple hardware IP(s) for secure
> > > > | enclaves like
> > EdgeLock-
> > > > | Enclave(ELE), SECO. The character device file descriptors
> > > > | /dev/<se>_mu*_ch* are the interface between
> > > > | userspace NXP's
> > secure-
> > > > | enclave shared library and the kernel driver.
> > > > |
> > > > | The ioctl(2)-based ABI is defined and documented in
> > > > | [include]<linux/firmware/imx/ele_mu_ioctl.h>.
> > > > | ioctl(s) are used primarily for:
> > > > | - shared memory management
> > > > | - allocation of I/O buffers
> > > > | - getting mu info
> > > > | - setting a dev-ctx as receiver to
> > > > | receive all the commands
> > from FW
> > > > | - getting SoC info
> > > > | - send command and receive command
> > > > | response
> > > ^
> > > > This is a rather uncommon approach. The kernel has interfaces to
> > > > abstract hardware. You completely bypass this if you expose
> > > > everything to the userspace.
> > >
> > > It is in-correct.
> > > Not everything, just exposed file-operation. and ioctl(s) for
> > > DMA(eable)
> > buffer allocation from reserved lower memory region.
> > > Things managed by Kernel:
> > > * Send/receive path to ELE, is managed by Kernel.
> > > * Receive/send patch to the ELE's slave NVM-manager, is managed by kernel.
> > > * Low power management handled by kernel driver. In case of
> > > low-power
> > state, ELE driver re-init the V2X IP as part of resume.
> > > * Other kernel management layers like NVMEM, kernel HWRNG, will use
> > > the
> > api(s) exposed by this driver.
> >
> > But you also expose an uAPI which allows the user to bypass everything
> > via sending arbitrary commands, right?
>
> Yes. But it's not unusual at all. The pattern of userspace sending
> commands directly to the kernel, is quite common
Please see below.
...
> > Some features require the device to be in LOCK_DOWN mode, which
> > requires secure-world eFuse write path only afterwards. But it seems
> > like NXP really wants to maintain two write paths.
> >
> > > * Low power management at Linux driver.
> >
> > The power-modes are selected via the ELE?
>
>
> Voltage regulation for i.MX93 in Linux kernel, is done by ELE.
>
> During Linux suspend-resume, Secure-enclave (V2X on i.MX95) part of
> wake-up domain, will be managed by secure-enclaves(ELE) part of
> always-on domain.
So to sum-up, please correct me if I got it wrong:
- NXP puts the ELE into the non-secure world, in case only one MU
exists. The reason for this is that the ELE is also used to handle
power-management.
- NXP exposes an uAPI which can be used to send arbitrary commands from
userspace to the ELE. (no filtering done yet)
--> Sounds to me that the userpace can influence the system behavior
very badly.
> > > * Linux HWRNG.
> > > * Loading the secondary runtime fw.
> >
> > What is a secondary runtime-fw?
> ELE FW size is larger than the size of ELE internal secure memory.
> Hence FW is split into two.
>
> Primary FW, is the FW, that enables features that helps for SoC boot-up.
> Secondary runtime FW, is the FW, that enables features like HSM.
Ah okay, thanks for the input.
> > To conclude this longly discussion:
...
> > I still have mixed feeling about the fusing (including the 1-MU case),
> > since it requires a secure-world OS in place once the LOCK_DOWN fuse was burned.
> > It's fine by me if NXP wants to have and wants to maintain a multi-path here.
>
> Write fuse API will be added, to allow writing fuses from secure world
> too.
This is a device life-cycle problem and if NXP decides to maintain
multiple write paths, depending on the runtime-SoC state, this is fine
by me.
What needs to be ensured is, that the fuse-issue doesn't exist for the
1-MU case (i.MX8ULP) as you said.
> > Last but least, the uAPI which can be used to send arbitrary ELE
> > commands seems unusual. But I don't know how secure-enclaves are
> > abstracted within the kernel, so these are just my two cents.
>
> it's not unusual at all. The pattern of userspace sending commands
> directly to the kernel via a queue is quite common like:
>
> GPUs: As you mentioned, userspace drivers (like those in Vulkan or
> CUDA) often build command buffers and submit them directly to the
> kernel or hardware.
That's right, but these drivers do at least some filtering on the OPs
and check if they are allowed. According your patchset, you just write
(se_if_fops_write()) the provided userspace buffer.
> Secure Enclaves: In systems like Intel SGX or AMD SEV, userspace
> applications interact with enclaves via ioctl or mmap interfaces,
> often sending structured commands or messages.
What I'm aware of is, that most secure-enclaves are switching to the
standard TPM API.
Regards,
Marco
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply [flat|nested] 17+ messages in thread* RE: [EXT] Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-11-11 13:14 ` Marco Felsch
@ 2025-11-12 11:38 ` Pankaj Gupta
2025-11-12 15:05 ` Marco Felsch
0 siblings, 1 reply; 17+ messages in thread
From: Pankaj Gupta @ 2025-11-12 11:38 UTC (permalink / raw)
To: Marco Felsch
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-doc@vger.kernel.org, Frank Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
> On 25-11-07, Pankaj Gupta wrote:
> > >> On 25-10-27, Pankaj Gupta wrote:
> > >>> On 25-09-27, Pankaj Gupta wrote:
>
> ...
>
> > > > It is not yet up-streamed to OPTEE-OS repo.
> > >
> > > My intention of adding the above OP-TEE discussion link was to point
> > > out that an ELE-FW bug exists which needs to be fixed.
>
> ...
>
> > > This adapts the timeout value to 100ms and seems more like an
> workaround.
> > >
> > There are additional fixes in OPTEE-OS, that will be part of LF Q4'25.
>
> Thanks for this info.
>
> > > However, can NXP confirm that the ELE concurrent access is possible
> > > without a previous ELE FW update?
> >
> > Fix in the ELE FW, released as part of LF Q3 2025, is a must to
> > include. OPTEE fixes are also needed. OPTEE fixes will be up-streamed
> > soon.
>
> Okay, so there are ELE-FW fixes too, thanks.
>
> ...
>
> > > Does this mean that all i.MX9x, i.MX10x and so on do have the the
> > > secure and non-secure MU setup? Or is it based on the SoC release date?
> > > Because regarding the datasheet the i.MX8ULP is newer than the
> > > i.MX93, therefore I assumed that the i.MX8ULP has two MUs as well.
> >
> > From i.MX93 and onward, there is only one RoT. Hence , it is designed
> > to have dedicated MU for each world.
>
> Okay.
>
> > > I checked the the NXP OP-TEE source code and found the following
> commit:
> > >
> > > 8<----------------
> > > commit 44388d37e68000ee50a9b1d656e0a60ae6614977
> > > Author: Sahil Malhotra <sahil.malhotra@nxp.com>
> > > Date: Tue Apr 1 20:04:44 2025 +0200
> > >
> > > core: imx: disable ELE on i.MX8ULP by default
> > >
> > > On i.MX8ULP, there is only one MU to communicate with ELE,
> > > which cannot be dedicated on OP-TEE side all the time.
> > > There may be ELE services running on Linux side, which can
> > > cause conflict with OP-TEE, So disabling ELE by default.
> > > Moreover i.MX8ULP also has CAAM, so HUK and Random number
> > > are coming from CAAM.
> > >
> > > Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
> > > Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
> > > 8<----------------
> > >
> > > So it's possible to configure the XRDC (configured in the TF-A) in a
> > > way to map the ELE access to the secure world. If I got the TF-A and OP-TEE
> commits right.
> > >
> > > To me this sound more like a NXP design decision to move the ELE to
> > > the non- secure and the CAAM to the secure world.
> >
> > As per the i.MX8ULP boot-up sequence and ELE's initial role in
> > boot-up, with CAAM co-exists, ELE is logical to be with Linux.
> >
> > Another point here that CAAM has 4 JR(s) and hence CAAM can be shared
> > between Linux and OPTEE-OS.
>
> Please see my answer below where you explained the ELE functions.
>
> ...
>
> > > i.MX8ULP is getting really interesting, though.
> > >
> > > May I ask what RoT is used by this SoC if there are two?
> > >
> > ELE is Root of Trust during secure boot.
> > For OPTEE-OS, CAAM is RoT.
>
> The i.MX8ULP is very interesting, since you also need to handle the SoC
> secure-state twice, right? However, this topic alone is worth it a standalone
> discussion thread, therefore no further comments.
>
> ...
>
> > > How does the i.MX8ULP fuse flow work, after the LOCK_DOWN fuse is
> blown?
> > There is no such issue on i.MX8ULP
> > >
> > > This was one of my main concers why having OP-TEE required in the
> > > first place, because the i.MX93 requires the that the fuse-request
> > > comes from the secure-world if the device is in LOCK_DOWN state.
> > >
> > > Is this also the case for the i.MX8ULP?
> > >
> >
> > No, this is not a valid case for i.MX8ULP.
>
> Thanks for the input.
>
> > > > > Also according your IOCTL docuementation you want to expose the
> > > > > whole device to the user-space?
> > > >
> > > > > | What: /dev/<se>_mu[0-9]+_ch[0-9]+
> > > > > | Date: Mar 2025
> > > > > | KernelVersion: 6.8
> > > > > | Contact: linux-imx@nxp.com, pankaj.gupta@nxp.com
> > > > > | Description:
> > > > > | NXP offers multiple hardware IP(s) for secure
> > > > > | enclaves like
> > > EdgeLock-
> > > > > | Enclave(ELE), SECO. The character device file descriptors
> > > > > | /dev/<se>_mu*_ch* are the interface between
> > > > > | userspace NXP's
> > > secure-
> > > > > | enclave shared library and the kernel driver.
> > > > > |
> > > > > | The ioctl(2)-based ABI is defined and documented in
> > > > > | [include]<linux/firmware/imx/ele_mu_ioctl.h>.
> > > > > | ioctl(s) are used primarily for:
> > > > > | - shared memory management
> > > > > | - allocation of I/O buffers
> > > > > | - getting mu info
> > > > > | - setting a dev-ctx as receiver to
> > > > > | receive all the commands
> > > from FW
> > > > > | - getting SoC info
> > > > > | - send command and receive command
> > > > > | response
> > > > ^
> > > > > This is a rather uncommon approach. The kernel has interfaces to
> > > > > abstract hardware. You completely bypass this if you expose
> > > > > everything to the userspace.
> > > >
> > > > It is in-correct.
> > > > Not everything, just exposed file-operation. and ioctl(s) for
> > > > DMA(eable)
> > > buffer allocation from reserved lower memory region.
> > > > Things managed by Kernel:
> > > > * Send/receive path to ELE, is managed by Kernel.
> > > > * Receive/send patch to the ELE's slave NVM-manager, is managed by
> kernel.
> > > > * Low power management handled by kernel driver. In case of
> > > > low-power
> > > state, ELE driver re-init the V2X IP as part of resume.
> > > > * Other kernel management layers like NVMEM, kernel HWRNG, will
> > > > use the
> > > api(s) exposed by this driver.
> > >
> > > But you also expose an uAPI which allows the user to bypass
> > > everything via sending arbitrary commands, right?
> >
> > Yes. But it's not unusual at all. The pattern of userspace sending
> > commands directly to the kernel, is quite common
>
> Please see below.
>
> ...
>
> > > Some features require the device to be in LOCK_DOWN mode, which
> > > requires secure-world eFuse write path only afterwards. But it seems
> > > like NXP really wants to maintain two write paths.
> > >
> > > > * Low power management at Linux driver.
> > >
> > > The power-modes are selected via the ELE?
> >
> >
> > Voltage regulation for i.MX93 in Linux kernel, is done by ELE.
> >
> > During Linux suspend-resume, Secure-enclave (V2X on i.MX95) part of
> > wake-up domain, will be managed by secure-enclaves(ELE) part of
> > always-on domain.
>
> So to sum-up, please correct me if I got it wrong:
>
> - NXP puts the ELE into the non-secure world, in case only one MU
> exists. The reason for this is that the ELE is also used to handle
> power-management.
For NXP SoCs with multi-MU(s) too, NXP proposes to put ELE driver into non-secure world.
>
> - NXP exposes an uAPI which can be used to send arbitrary commands from
> userspace to the ELE. (no filtering done yet)
It is not correct to say that no filtering is done.
Before sending as well as after receiving the message, the message header of the buffers
are parsed to check:
- TX-buffer with Command-tag is allowed to be sent, RX-buffer with response-tag is allowed to be received, without logging errors.
- TX buffer size & Rx-Buffer size should match the size mentioned in the buffer.
- FW version from the header is checked, if required secondary or runtime FW Is loaded, before forwarding the request to ELE.
- In certain cases especially for exceptions, the message IDs are also compared.
>
> --> Sounds to me that the userpace can influence the system behavior
> very badly.
>
Messages created and sent by User-space library(https://github.com/nxp-imx/imx-secure-enclave), are scrutinized as stated above in the kernel driver.
Moreover,
As part of this library, message creation, send-receive, IOCTLS etc. kernel interface implementation logic, is not exposed to users of this library.
With the help of secure-boot and IMA-EVM, rootfs can be restricted to not allow any new application or modified userspace library, to execute.
This way bad impact to the system behavior can be prevented.
> > > > * Linux HWRNG.
> > > > * Loading the secondary runtime fw.
> > >
> > > What is a secondary runtime-fw?
> > ELE FW size is larger than the size of ELE internal secure memory.
> > Hence FW is split into two.
> >
> > Primary FW, is the FW, that enables features that helps for SoC boot-up.
> > Secondary runtime FW, is the FW, that enables features like HSM.
>
> Ah okay, thanks for the input.
>
> > > To conclude this longly discussion:
>
> ...
>
> > > I still have mixed feeling about the fusing (including the 1-MU
> > > case), since it requires a secure-world OS in place once the LOCK_DOWN
> fuse was burned.
> > > It's fine by me if NXP wants to have and wants to maintain a multi-path
> here.
> >
> > Write fuse API will be added, to allow writing fuses from secure world
> > too.
>
> This is a device life-cycle problem and if NXP decides to maintain multiple write
> paths, depending on the runtime-SoC state, this is fine by me.
>
> What needs to be ensured is, that the fuse-issue doesn't exist for the 1-MU
> case (i.MX8ULP) as you said.
As said above "Write fuse API will be added, to allow writing fuses from secure world too."
This will be true for 1 MU or multi-MU.
>
> > > Last but least, the uAPI which can be used to send arbitrary ELE
> > > commands seems unusual. But I don't know how secure-enclaves are
> > > abstracted within the kernel, so these are just my two cents.
> >
> > it's not unusual at all. The pattern of userspace sending commands
> > directly to the kernel via a queue is quite common like:
> >
> > GPUs: As you mentioned, userspace drivers (like those in Vulkan or
> > CUDA) often build command buffers and submit them directly to the
> > kernel or hardware.
>
> That's right, but these drivers do at least some filtering on the OPs and check if
> they are allowed. According your patchset, you just write
> (se_if_fops_write()) the provided userspace buffer.
We are validating the buffer size against the size mentioned in the buffer header.
Refer above comments for more details.
> > Secure Enclaves: In systems like Intel SGX or AMD SEV, userspace
> > applications interact with enclaves via ioctl or mmap interfaces,
> > often sending structured commands or messages.
>
> What I'm aware of is, that most secure-enclaves are switching to the standard
> TPM API.
In case of NXP SoC with ELE HW IP, ELE is considered as on-SoC TPM. No additional or external TPM is needed, if ELE is present on SoC.
>
> Regards,
> Marco
>
Regards
Pankaj
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [EXT] Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-11-12 11:38 ` Pankaj Gupta
@ 2025-11-12 15:05 ` Marco Felsch
2025-11-17 5:38 ` Pankaj Gupta
0 siblings, 1 reply; 17+ messages in thread
From: Marco Felsch @ 2025-11-12 15:05 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-doc@vger.kernel.org, Frank Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
On 25-11-12, Pankaj Gupta wrote:
...
> > > Voltage regulation for i.MX93 in Linux kernel, is done by ELE.
> > >
> > > During Linux suspend-resume, Secure-enclave (V2X on i.MX95) part of
> > > wake-up domain, will be managed by secure-enclaves(ELE) part of
> > > always-on domain.
> >
> > So to sum-up, please correct me if I got it wrong:
> >
> > - NXP puts the ELE into the non-secure world, in case only one MU
> > exists. The reason for this is that the ELE is also used to handle
> > power-management.
>
> For NXP SoCs with multi-MU(s) too, NXP proposes to put ELE driver into
> non-secure world.
With the ELE-FW and OP-TEE OS fix applied both worlds can communicate.
Therefore it doesn't matter and I didn't mentioned it explicit above.
That beeing said, with both worlds capable to talk to ELE and the ELE
beeing very system critical, both worlds have to agree to the
responsibilities, e.g. OP-TEE OS is not allow to manipulate the
power-state behind the back of Linux.
> > - NXP exposes an uAPI which can be used to send arbitrary commands from
> > userspace to the ELE. (no filtering done yet)
>
> It is not correct to say that no filtering is done.
> Before sending as well as after receiving the message, the message header of the buffers
> are parsed to check:
> - TX-buffer with Command-tag is allowed to be sent, RX-buffer with response-tag is allowed to be received, without logging errors.
I really don't want to step to deep into this, but that beeing said. If
you refer to cmd_tag, than this tag is used by your below mentioned
library also for NVM access. NVM is clearly something we do have a
linux-framework and uAPI for.
> - TX buffer size & Rx-Buffer size should match the size mentioned in the buffer.
> - FW version from the header is checked, if required secondary or runtime FW Is loaded, before forwarding the request to ELE.
> - In certain cases especially for exceptions, the message IDs are also compared.
>
> >
> > --> Sounds to me that the userpace can influence the system behavior
> > very badly.
> >
>
> Messages created and sent by User-space
> library(https://github.com/nxp-imx/imx-secure-enclave), are
> scrutinized as stated above in the kernel driver.
This is uAPI which can be used by everyone and because your library may
not implement access to power-managment calls doesn't mean that other
libs do. I'm not sure if your proposed driver will block such attempts
from userspace.
> Moreover,
> As part of this library, message creation, send-receive, IOCTLS etc.
> kernel interface implementation logic, is not exposed to users of this
> library.
Your library is not the interface, the interface is the uAPI exposed by
the kernel. This interface/your driver needs to handle valid and invalid
access, e.g. hsm -> valid, nvm -> not valid since it is abstracted via
NVMEM.
> With the help of secure-boot and IMA-EVM, rootfs can be restricted to
> not allow any new application or modified userspace library, to
> execute.
>
> This way bad impact to the system behavior can be prevented.
Sorry but I really have to say that I have to NACK. Your interface is
the kernel uAPI and not some NXP userspace library.
An attacker could gain runtime system access and poke the ELE with
arbitrary commands till he finds a fw-bug using the kernel uAPI (not
your library of course).
> > > > > * Linux HWRNG.
> > > > > * Loading the secondary runtime fw.
> > > >
> > > > What is a secondary runtime-fw?
> > > ELE FW size is larger than the size of ELE internal secure memory.
> > > Hence FW is split into two.
> > >
> > > Primary FW, is the FW, that enables features that helps for SoC boot-up.
> > > Secondary runtime FW, is the FW, that enables features like HSM.
> >
> > Ah okay, thanks for the input.
> >
> > > > To conclude this longly discussion:
> >
> > ...
> >
> > > > I still have mixed feeling about the fusing (including the 1-MU
> > > > case), since it requires a secure-world OS in place once the LOCK_DOWN
> > fuse was burned.
> > > > It's fine by me if NXP wants to have and wants to maintain a multi-path
> > here.
> > >
> > > Write fuse API will be added, to allow writing fuses from secure world
> > > too.
> >
> > This is a device life-cycle problem and if NXP decides to maintain multiple write
> > paths, depending on the runtime-SoC state, this is fine by me.
> >
> > What needs to be ensured is, that the fuse-issue doesn't exist for the 1-MU
> > case (i.MX8ULP) as you said.
>
> As said above "Write fuse API will be added, to allow writing fuses
> from secure world too."
> This will be true for 1 MU or multi-MU.
In your previous mail you just said that there is no such issue with the
write path. Now you say that the single-MU case needs the same
workaround.. At least I have read it that way.
> > > > Last but least, the uAPI which can be used to send arbitrary ELE
> > > > commands seems unusual. But I don't know how secure-enclaves are
> > > > abstracted within the kernel, so these are just my two cents.
> > >
> > > it's not unusual at all. The pattern of userspace sending commands
> > > directly to the kernel via a queue is quite common like:
> > >
> > > GPUs: As you mentioned, userspace drivers (like those in Vulkan or
> > > CUDA) often build command buffers and submit them directly to the
> > > kernel or hardware.
> >
> > That's right, but these drivers do at least some filtering on the OPs and check if
> > they are allowed. According your patchset, you just write
> > (se_if_fops_write()) the provided userspace buffer.
>
> We are validating the buffer size against the size mentioned in the
> buffer header.
> Refer above comments for more details.
>
> > > Secure Enclaves: In systems like Intel SGX or AMD SEV, userspace
> > > applications interact with enclaves via ioctl or mmap interfaces,
> > > often sending structured commands or messages.
> >
> > What I'm aware of is, that most secure-enclaves are switching to the standard
> > TPM API.
>
> In case of NXP SoC with ELE HW IP, ELE is considered as on-SoC TPM. No
> additional or external TPM is needed, if ELE is present on SoC.
I said "TPM API" not "TPM device", may it be fTPM or dTPM. I think AMD
switched to fTPM, so no special userspace-requirements must be
fulfilled. However, this is also off-topic.
Regards,
Marco
>
> >
> > Regards,
> > Marco
> >
>
> Regards
> Pankaj
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [EXT] Re: [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
2025-11-12 15:05 ` Marco Felsch
@ 2025-11-17 5:38 ` Pankaj Gupta
0 siblings, 0 replies; 17+ messages in thread
From: Pankaj Gupta @ 2025-11-17 5:38 UTC (permalink / raw)
To: Marco Felsch
Cc: Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-doc@vger.kernel.org, Frank Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
> > > > Voltage regulation for i.MX93 in Linux kernel, is done by ELE.
> > > >
> > > > During Linux suspend-resume, Secure-enclave (V2X on i.MX95) part
> > > > of wake-up domain, will be managed by secure-enclaves(ELE) part
> > > > of always-on domain.
> > >
> > > So to sum-up, please correct me if I got it wrong:
> > >
> > > - NXP puts the ELE into the non-secure world, in case only one MU
> > > exists. The reason for this is that the ELE is also used to handle
> > > power-management.
> >
> > For NXP SoCs with multi-MU(s) too, NXP proposes to put ELE driver
> > into non-secure world.
>
> With the ELE-FW and OP-TEE OS fix applied both worlds can communicate.
> Therefore it doesn't matter and I didn't mentioned it explicit above.
>
> That beeing said, with both worlds capable to talk to ELE and the ELE
> beeing very system critical, both worlds have to agree to the
> responsibilities, e.g. OP- TEE OS is not allow to manipulate the power-state behind the back of Linux.
Yes, your understanding is correct.
>
> > > - NXP exposes an uAPI which can be used to send arbitrary
> > > commands from userspace to the ELE. (no filtering done yet)
> >
> > It is not correct to say that no filtering is done.
> > Before sending as well as after receiving the message, the message
> > header of the buffers are parsed to check:
> > - TX-buffer with Command-tag is allowed to be sent, RX-buffer with response-tag is allowed to be received, without logging errors.
> I really don't want to step to deep into this, but that beeing said.
> If you refer to cmd_tag, than this tag is used by your below mentioned
> library also for NVM access. NVM is clearly something we do have a
> linux-framework and uAPI for.
Will add a command parser in v20, which will prevent sending any arbitrary command.
>
> > - TX buffer size & Rx-Buffer size should match the size mentioned in
> > the
> buffer.
> > - FW version from the header is checked, if required secondary or
> > runtime
> FW Is loaded, before forwarding the request to ELE.
> > - In certain cases especially for exceptions, the message IDs are
> > also
> compared.
> >
> > >
> > > --> Sounds to me that the userpace can influence the system behavior
> > > very badly.
> > >
> >
> > Messages created and sent by User-space
> > library(https://eur01.safelinks.protection.outlook.com/?url=https%3A
> > %2
> > F%2Fgithub.com%2Fnxp-imx%2Fimx-secure-
> enclave&data=05%7C02%7Cpankaj.gupta%40nxp.com%7Ce1d7cb78bda54edf
> 36d608de21fce1f6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> 38985567165069017%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D%3D%7C0%7C%7C%7C&sdata=oE5nFyHRdW9ouWMy3VgiaGcgY7XKF4oZ
> Mbnt95HZ1%2F8%3D&reserved=0), are scrutinized as stated above in the
> kernel driver.
>
> This is uAPI which can be used by everyone and because your library
> may not implement access to power-managment calls doesn't mean that other libs do.
> I'm not sure if your proposed driver will block such attempts from userspace.
Will add a command parser in v20, which will prevent sending any arbitrary command & any such attempt from userspace.
>
> > Moreover,
> > As part of this library, message creation, send-receive, IOCTLS etc.
> > kernel interface implementation logic, is not exposed to users of
> > this library.
>
> Your library is not the interface, the interface is the uAPI exposed
> by the kernel.
Agreed, that library is not the interface here. I never meant that.
I was trying to put the point that in order to exchange any arbitrary message, rootfs needs to be compromised
- either to allow any arbitrary/un-authorized application to send any arbitrary message,
- or to allow executing compromised library.
But Yes, you are correct that here we are talking kernel driver, not userspace.
> This interface/your driver needs to handle valid and invalid access,
> e.g. hsm -> valid, nvm -> not valid since it is abstracted via NVMEM.
Kernel driver do ensure to handle only valid, and discard invalid access.
The in-coming command with command_tag are given to the dev_context which is marked receiver.
If the receiver is not assigned/set, it will be discarded.
The in-coming command with resp_tag are given to the dev_context which is the initiator of the initial command request.
If this is not followed, it will deny the message exchanged.
Will add a command parser in v20, which will prevent sending any arbitrary command.
>
> > With the help of secure-boot and IMA-EVM, rootfs can be restricted
> > to not allow any new application or modified userspace library, to
> > execute.
> >
> > This way bad impact to the system behavior can be prevented.
>
> Sorry but I really have to say that I have to NACK. Your interface is
> the kernel uAPI and not some NXP userspace library.
Will add a command parser in v20, which will prevent sending any arbitrary command from kernel driver.
>
> An attacker could gain runtime system access and poke the ELE with
> arbitrary commands till he finds a fw-bug using the kernel uAPI (not
> your library of course).
Though the same command parser exists in ELE FW, which discards any arbitrary command.
Will add a command parser in v20, which will discard any arbitrary command and power management API(s), from uAPI.
Request you or other, to share any comment apart from this, that can be addressed in v20.
Will send v20 by end of this week.
Thanks & regards
Pankaj
>
> > > > > > * Linux HWRNG.
> > > > > > * Loading the secondary runtime fw.
> > > > >
> > > > > What is a secondary runtime-fw?
> > > > ELE FW size is larger than the size of ELE internal secure memory.
> > > > Hence FW is split into two.
> > > >
> > > > Primary FW, is the FW, that enables features that helps for SoC boot-up.
> > > > Secondary runtime FW, is the FW, that enables features like HSM.
> > >
> > > Ah okay, thanks for the input.
> > >
> > > > > To conclude this longly discussion:
> > >
> > > ...
> > >
> > > > > I still have mixed feeling about the fusing (including the
> > > > > 1-MU case), since it requires a secure-world OS in place once
> > > > > the LOCK_DOWN
> > > fuse was burned.
> > > > > It's fine by me if NXP wants to have and wants to maintain a
> > > > > multi-path
> > > here.
> > > >
> > > > Write fuse API will be added, to allow writing fuses from secure
> > > > world too.
> > >
> > > This is a device life-cycle problem and if NXP decides to maintain
> > > multiple write paths, depending on the runtime-SoC state, this is
> > > fine by
> me.
> > >
> > > What needs to be ensured is, that the fuse-issue doesn't exist for
> > > the 1-MU case (i.MX8ULP) as you said.
> >
> > As said above "Write fuse API will be added, to allow writing fuses
> > from secure world too."
> > This will be true for 1 MU or multi-MU.
>
> In your previous mail you just said that there is no such issue with
> the write path. Now you say that the single-MU case needs the same
> workaround.. At least I have read it that way.
>
> > > > > Last but least, the uAPI which can be used to send arbitrary
> > > > > ELE commands seems unusual. But I don't know how
> > > > > secure-enclaves are abstracted within the kernel, so these are just my two cents.
> > > >
> > > > it's not unusual at all. The pattern of userspace sending
> > > > commands directly to the kernel via a queue is quite common like:
> > > >
> > > > GPUs: As you mentioned, userspace drivers (like those in Vulkan
> > > > or
> > > > CUDA) often build command buffers and submit them directly to
> > > > the kernel or hardware.
> > >
> > > That's right, but these drivers do at least some filtering on the
> > > OPs and check if they are allowed. According your patchset, you
> > > just write
> > > (se_if_fops_write()) the provided userspace buffer.
> >
> > We are validating the buffer size against the size mentioned in the
> > buffer header.
> > Refer above comments for more details.
> >
> > > > Secure Enclaves: In systems like Intel SGX or AMD SEV, userspace
> > > > applications interact with enclaves via ioctl or mmap
> > > > interfaces, often sending structured commands or messages.
> > >
> > > What I'm aware of is, that most secure-enclaves are switching to
> > > the standard TPM API.
> >
> > In case of NXP SoC with ELE HW IP, ELE is considered as on-SoC TPM.
> > No additional or external TPM is needed, if ELE is present on SoC.
>
> I said "TPM API" not "TPM device", may it be fTPM or dTPM. I think AMD
> switched to fTPM, so no special userspace-requirements must be fulfilled.
> However, this is also off-topic.
>
> Regards,
> Marco
>
^ permalink raw reply [flat|nested] 17+ messages in thread