* [PATCH v19 0/7] firmware: imx: driver for NXP secure-enclave
@ 2025-09-26 21:09 Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 1/7] Documentation/firmware: add imx/se to other_interfaces Pankaj Gupta
` (8 more replies)
0 siblings, 9 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
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.
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.
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.
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.
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.
- 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.
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.
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.
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.
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.
S3. Having one implementation is beneficial in the following ways:
- Adding the support for it to OP-TEE OS do not requires ELE-FW.
- 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.
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.
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.
-------
firmware: imx: driver for NXP secure-enclave
The NXP's i.MX EdgeLock Enclave, a HW IP creating an embedded secure
enclave within the SoC boundary to enable features like
- HSM
- SHE
- V2X
Communicates via message unit with linux kernel. This driver is
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 can communicate on single MU.
It exists on some i.MX processors. e.g. i.MX8ULP, i.MX93 etc.
Changes in v19:
1/7
- Added 9 lines to the Introduction from line 73-82.
3/7
- 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 OP-TEE OS (one or
more), that needs to be shared between them.."
Reference:
- Link to v18: https://lore.kernel.org/r/20250619-imx-se-if-v18-0-c98391ba446d@nxp.com
Changes in v18:
1/7
- Wrap both diagrams above in literal code block by using double-colon
3/7 & 5/7
- Collected Frank's R-b tag.
2/7, 4/7, 6/7 & 7/7
- No changes
Reference:
- Link to v17: https://lore.kernel.org/r/20250426-imx-se-if-v17-0-0c85155a50d1@nxp.com
Changes in v17:
- Changes to 3/7 & 5/7: to wrap code text at 80 character whereever possible.
Reference:
- Link to v16: https://lore.kernel.org/r/20250409-imx-se-if-v16-0-5394e5f3417e@nxp.com
Changes in v16:
- commit 3/7 and 4/7 are moved to end commits making them as 6/7 and 7/7 respectively.
- No change in 1/7 & 2/7.
7/7
- Collected Frank's R-b tag.
6/7
- commit message is updated to wrap at 75 characters.
5/7
- func add_b_desc_to_pending_list, removed the initialization of b_desc to
NULL.
- variable timeout in func ele_msg_rcv(), is renamed to timeout_ms.
- struct se_if_priv, member variable se_rcv_msg_timeout, is renamed to
se_rcv_msg_timeout_ms.
- in func load_firmware, move the label exit after dma_free_coherent.
4/7
- commit message is updated to wrap at 75 characters.
3/7
- ele_debug_dump, updated the assignment of keep_logging.
- ele_fw_authenticate function definition is updated to take two address
as arguments.
Reference:
- Link to v15: https://lore.kernel.org/r/20250407-imx-se-if-v15-0-e3382cecda01@nxp.com
Changes in v15:
- Patch 3/6 is split into two:
- 3/7: arm64: dts: imx8ulp-evk: add reserved memory property
- 4/7: arm64: dts: imx8ulp: add nxp secure enclave firmware
- No change in 1/7 & 2/7.
7/7
- removed the se_intance_id structure member variable.
- replace variable name from wait to timeout.
- used 'goto' to follow the common exit path calling "release_firmware(fw);" in case of error path.
- removed TBD string.
- Used ARRAY_SIZE(pending_lists).
- moved init_device_context after init_misc_device_context.
- defined err as long to avoid force convert in func
- added se_rcv_msg_timeout to priv, to control probe/suspend/resume per interface.
6/7
- removed the se_intance_id structure member variable.
- Added dev_ctx to the structure se_clbk_handle, too.
- Collected Frank's R-b tag.
5/7
- removed the se_intance_id structure member variable.
- since added se_if_probe_cleanup to devm, se_if_remove() is redundant. hence removed it.
- rename se_add_msg_chksum to se_get_msg_chksum
- added check if msg-size is 4 byte aligned.
- Fixed multiline comments.
- ele_debug_dump api is updated as part of comment disposition like single setting of flag "keep_logging" & adding if (ret).
- moved dev_err to dev_dbg, for imem save/restore functions.
- moved func get_se_if_name, from 7/7 to here.
3/7
- Updated the commit message.
- split the current patch into two:
-- 3/7 for board dts, and
-- 4/7 for chip dts
Reference:
- Link to v14: https://lore.kernel.org/r/20250327-imx-se-if-v14-0-2219448932e4@nxp.com
Changes in v14:
- Patch 5/5 is split into two:
- firmware: drivers: imx: adds miscdev
- Introduce dev-ctx dedicated to private.
-- Base patch before enabling misc-device context, to have the send-receive path, based on device context.
- No change in 1/6 & 2/6.
- Copied change logs from individual commits.
6/6
- moved definition of func se_load_firmware, from 4/6 patch to this patch.
- split init_device_context to init_misc_device_context.
- Different value of se_rcv_msg_timeout is required to be set. Receiving the response of 4K RSA operation can to take upto 3 minutes.
This long value cannot be set during Linux: boot-up and suspend-resume.
Hence, it will be set to default small-value during Linux: boot-up and suspend-resume.
- func se_dev_ctx_cpy_out_data(), in either case: do_cpy true or false, the clean-up needs to be done and it is implemented like wise.
Once do_cpy is false, no need to continue copy to user buffer. But continue to do clean-up. hence cannot return.
And every dev-ctx operation is done after taking the lock. Hence, two operations with same dev-ctx is not possible in parallel.
- func "init_device_context", for 0th misc dev_ctx, which is created at the time of probe, the device memory management is required. hence there is a difference.
- func "init_device_context", dev_er is replaced with return dev_err_probe.
- func "init_device_context", devm_add_action is replaced by devm_add_action_reset.
- removed type-cast from func se_ioctl_get_se_soc_info_handler().
- used scoped_cond_guard(mutex, _intr, return -EBUSY, &<mutex_lock>)
- combined dev_err & dev_dbg to one dev_err in se_if_fops_read().
- removed the structure member "se_shared_mem_mgmt->secure_mem".
4/6
- trimmed the ele_fetch_soc_info.
- removed the function ptr "se_info->se_fetch_soc_info" and replaced with ele_fetch_soc_info.
- moved definition of func se_load_firmware, to 6/6 patch.
- Different SoC, different ways to fetch soc_info. Generic function declaration for ele_fetch_soc_info() is needed. Hence wrapping ele_get_info() in it.
- Updated Kconfig help text for assertive tone.
- func ele_debug_dump is updated, to remove constructing the format string.
- removed the macro usage for SOC_ID_MASK.
- used low case hex number.
- Condition will never occur, where msg_len satisfy the following condition "msg_len % 4 != 0". Err msg is added if it occurs.
- Function description is added to se_add_msg_crc.
- timeout is added to function ele_msg_rcv, in 5/5 patch.
- local variable "header" is initialized with "tx_msg" and replaced "return err" with "return tx_msg_sz" in func ele_msg_send().
- replace function name from "exception_for_size" to "check_hdr_exception_for_sz"
- replaced "return ret > 0 ? 0 : -1;" with "return ret > 0 ? 0 : ret;" in func "se_save_imem_state".
- func "se_restore_imem_state", to return if the condition is false to proceed.
- removed casting by (void *).
- removed devm_kasprintf and done direct allocatiion for attr->soc_id = "i.MX8ULP" & attr->soc_id = "i.MX8ULP", & attr->family.
- Followed Reverse christmas tree order, whereever missing.
- There is no return if ele_fw_authenticate fails. Execution flow continue forward and execute the fucn dma_free_coherent().
- The loop is not for retry. The loop is needed to load secondary fw followed by loading primary fw, first. This is the case when ELE also got reset.
- dev_err_probe is corrected in func "se_if_request_channel".
3/6
-
Reference:
- Link to v13: https://lore.kernel.org/r/20250311-imx-se-if-v13-0-9cc6d8fd6d1c@nxp.com
Changes in v13:
5/5
- Updated the commit message for imperative mood.
- Remove the usage of macros- NODE_NAME, GET_ASCII_TO_U8, GET_IDX_FROM_DEV_NODE_NAME.
- Clean-up the return path by replacing "ret = -<err>; return ret;" with "return -<err>;"
- Clean-up the return path by replacing "ret = -<err>; goto exit;" with "return -<err>;"
- Removed goto statements from the entire driver, where there is no common code at function's exit.
- Fixes the check-patch erros reported with flag "--strict"
- Replaced devm_add_action, with devm_add_action_or_reset
- Removed the un-necesary and obvious code comments.
- Removed dev_probe_err at the exit of function se_if_probe().
4/5
- Clean-up the return path by replacing "ret = -<err>; return ret;" with "return -<err>;"
- Clean-up the return path by replacing "ret = -<err>; goto exit;" with "return -<err>;"
- Removed goto statements from the entire driver, where there is no common code at function's exit.
- fixes the check-patch erros reported with flag "--strict"
- removed the un-necesary and obvious code comments.
- variable received msg timeout to be different at boot-up & suspend/resume and send/recv ioctlis.
3/5
- compatible string is modified from "fsl,imx8ulp-se" to "fsl,imx8ulp-se-ele-hsm".
- updated the alias name.
2/5
- compatible string is modified from "fsl,imx8ulp-se" to "fsl,imx8ulp-se-ele-hsm".
- compatible string is modified from "fsl,imx93-se" to "fsl,imx93-se-ele-hsm".
- compatible string is modified from "fsl,imx95-se" to "fsl,imx95-se-ele-hsm".
- Mis-understood the +1 from Conor. Hence dropped the Reviewed-by tag.
- Collected Rob's R-b tag on v7 (https://lore.kernel.org/all/172589152997.4184616.5889493628960272898.robh@kernel.org/)
1/5
- No change
Reference:
- Link to v12: https://lore.kernel.org/r/20250120-imx-se-if-v12-0-c5ec9754570c@nxp.com
Changes in v12:
5/5
- increased the wait-timeout.
4/5
- rename flag "handle_susp_resm" to "imem_mgmt"
- moved the buffer allocation ot load_fw->imem.buf, to se_probe_if.
- setting imem state at initialization.
3/5
- No change
2/5
- No change
1/5
- No change
Reference:
- Link to v11: https://lore.kernel.org/r/20241220-imx-se-if-v11-0-0c7e65d7ae7b@nxp.com
Changes in v11:
5/5
- devname is constructed by concatinating get_se_if_name(se_if_id) & se_if_instance_id.
- ele_rcv_msg(), is updated to add the wait_interruptible_timeout for the non-NVM-Daemon message exchanges, such that in case of no response from FW,
Linux donot hangs.
- added a new helper function get_se_if_name(), to return the secure-enclave interface owner's name string.
- added a new helper function get_se_soc_id(), to return the secure-enclave's SoC id.
4/5
- moved the se_if_node_info member "soc_register", to the struct "se_if_node_info_list"; as soc registration done once, not per interface.
- moved the se_if_node_info member "se_fetch_soc_info", to the struct "se_if_node_info_list"; as soc info fetching is done once, not per interface.
- Added two member variable se_if_id and se_if_instance_id to struct se_if_defines.
- removed the member "se_name" from struct "se_if_node_info". Rather, it will constructed by concatinating get_se_if_name(se_if_id) & se_if_instance_id.
- moved the static global variable "se_version", to the newly created structure "struct se_var_info".
- moved the member "struct se_fw_load_info load_fw" of "se_if_node_info_list", to the newly created structure "struct se_var_info".
- Replaced RUNTIME_PM_OPS with SET_SYSTEM_SLEEP_PM_OPS, in power-managment ops.
3/5
- No change
2/5
- No change
1/5
- No change
Reference:
- Link to v10: https://lore.kernel.org/r/20241104-imx-se-if-v10-0-bf06083cc97f@nxp.com
v10: firmware: imx: driver for NXP secure-enclave
Changes in v10:
5/5
- replaced the u8, u16, u32, u64, with __u8, __u16, __u32, __u64 in
'include/uapi/linux/se_ioctl.h'.
4/5
- No change
3/5
- No change
2/5
- No change
1/5
- No change
Reference:
- Link to v9: https://lore.kernel.org/r/20241016-imx-se-if-v9-0-fd8fa0c04eab@nxp.com
Changes in v9:
4/5
- change se_if_remove function signature, required after rebase to v6.12-rc1.
- move the info->macros to a structure "struct se_if_defines if_defs".
- Removed "info" from "struct se_if_defines if_defs".
- Moved "mem_pool" from "struct se_if_defines if_defs" to "priv".
- Fetching "info" using container-of.
5/5
- Fetching "info" using container-of.
- Fixed issue reported by sparse.
Reference:
- Link to v8: https://lore.kernel.org/r/20241015-imx-se-if-v8-0-915438e267d3@nxp.com
Changes in v8:
5/5
- Remove the check for SE_IF_CTX_OPENED.
- replaced dev_ctx->priv-dev, priv->dev, whereever possible.
- func "if_misc_deregister" moved before func "init_device_context".
- func "init_device_context" before func "se_ioctl_cmd_snd_rcv_rsp_handler".
- func "se_if_fops_write" and "se_if_fops_read", are moved after func "se_ioctl_get_mu_info".
- non static functions "se_dev_ctx_cpy_out_data, se_dev_ctx_shared_mem_cleanup & init_device_context" are moved static and local scope.
- Removed back & forth between the two structs "struct se_if_device_ctx *dev_ctx" and "struct se_shared_mem_mgmt_info *se_shared_mem_mgmt"
- removed the NULL check for bdesc.
- fops_open, is corrected for acquiring the fops_lock.
- Fops_close, mutex unlock is removed. Infact check for waiting_rsp_clbk_hdl.dev_ctx, is removed.
- sema_init(&dev_ctx->fops_lock, 1);, replaced with Mutex.
- structure member se_notify, is removed.
4/5
- removed initializing err to zero in func ele_fetch_soc_info(),
- replaced 'return 0', with 'goto exit', if the condition (!priv->mem_pool) is true.
- replaced "struct *dev" with "struct se_if_priv *priv", in base_message API(s) and others.
- Created a separate structure "struct se_if_defines" to maintain interface's fixed values like cmd_tag, rsp_tag, success_tag etc.
- removed the macros "WORD_SZ", "SOC_VER_MASK", "DEFAULT_IMX_SOC_VER", "RESERVED_DMA_POOL".
- Added handling for "ctrl+c", by postponing the interrupt, till the response to the "command in flight" is received.
- Removed the mutext lock "se_if_lock".
- furnction prototype for "se_save_imem_state" and "se_restore_imem_state", is changed to pass "imem" by reference.
- Added a new structure "struct se_fw_load_info", dedicated to contain FW loading relevant info. It is a member of struct info_list.
- split "imem_mgmt_file_in_rfs" into two "prim_fw_nm_in_rfs" and "seco_fw_nm_in_rfs", to be part of "struct se_fw_load_info".
- moved the function "se_load_firmware" prior to func "if_mbox_free_channel".
- function "se_load_firmware" is updated to use "request_firmware", instead of "request_firmware_no_wait".
- function "se_load_firmware" is updated to load "primary" fw image, if the imem_state is not BAD. Then load the "secondary FW" image.
- Added a new mutex_lock in the function "se_load_firmware", for ensuring FW loading done once, when there are multiple application are in play.
- instead of "wait_queue_head_t wq", used "sruct completion".
- add devm_add_action with action as se_if_probe_cleanup.
Reference:
- Link to v7: https://lore.kernel.org/r/20240904-imx-se-if-v7-0-5afd2ab74264@nxp.com
Changes in v7:
5/5
- struct se_clbk_handle, is added with a member struct se_if_device_ctx *dev_ctx.
- func call to ele_miscdev_msg_rcv() & ele_miscdev_msg_send(), are removed.
- func se_ioctl_cmd_snd_rcv_rsp_handler(), is modified to remove the func call to ele_miscdev_msg_rcv() & ele_miscdev_msg_send()
- func se_ioctl_cmd_snd_rcv_rsp_handler is callig func ele_msg_send_rcv(), instead.
- Mutext "se_cmd_if_lock", handling is removed from this patch.
- func ele_miscdev_msg_send() is replaced with func ele_msg_send(), in fops_write.
- func ele_miscdev_msg_rcv() is replaced with func ele_msg_rcv(), in fops_read.
- fops_open is modified to create the new dev_ctx instance (using func init_device_context()), which is not registered as miscdev.
- Only one dev_ctx is registered as miscdev and its reference is stored in the struct se_if_priv, as priv_dev_ctx.
- Separate func cleanup_se_shared_mem() & func init_se_shared_mem(), for shared memory handling part of struct dev_ctx.
- Input param for func(s) ele_msg_rcv(), ele_msg_send() & ele_msg_send_rcv(), is replaced from struct se_if_priv to struct se_if_device_ctx.
4/5
- A new structure is defined name struct "se_clbk_handle", to contain members processed in mailbox call-back function.
- "struct se_if_priv" is modified to contain the two structures of "se_clbk_handle" - waiting_rsp_clbk_hdl & cmd_receiver_clbk_hdl.
- func ele_msg_rcv() is modified to take a new additional input reference param "struct se_clbk_handle *se_clbk_hdl".
- func ele_msg_send() is modified to take a new additional input tx_msg_sz.
- func ele_msg_send_rcv(), is modified to take 2 more inputs - tx_msg_sz & exp_rx_msg_sz.
- func se_val_rsp_hdr_n_status(), is modified to take input of rx_msg buffer, instead of header value, as input param.
- each caller of the func ele_msg_send_rcv(), is sending these two additional input params.
- func se_if_callback(), is modified to work on two structures of "se_clbk_handle" - waiting_rsp_clbk_hdl & cmd_receiver_clbk_hdl.
- Variable "max_dev_ctx", is removed from info & priv struture, as well its usage.
- New member variable "se_img_file_to_load", is added to structure "priv".
- Other member variables - rx_msg(ptr), rx_msg_sz, completion done & list of dev_ctxs, is removed from priv struture, along with their usage.
- func se_resume(), updated to wakeup the two "wq", part of "struct se_clbk_handle": priv->waiting_rsp_clbk_hdl & priv->cmd_receiver_clbk_hdl.
3/5
- Node name is changed from senclave-firmware@0 to "secure-enclave"
2/5
- Node name is changed to "secure-enclave".
Reference:
- Link to v6: https://lore.kernel.org/r/20240722-imx-se-if-v6-0-ee26a87b824a@nxp.com
Changes in v6:
5/5
- replaced scope_gaurd with gaurd.
4/5
- replaced scope_gaurd with gaurd.
- remove reading the regs property from dtb.
- Added NULL check for priv data fetched from device, as a sanity check, for ele_base_msg apis)
3/5
- replace firmware with senclave-firmware.
2/5
- replace firmware with senclave-firmware.
- drop description for mbox
- Replaced "items:" with maxItems:1 for "memory-region"
- Replaced "items:" with maxItems:1 for "sram"
- remove regs property.
- remove "$nodename"
Reference:
- Link to v5: https://lore.kernel.org/r/20240712-imx-se-if-v5-0-66a79903a872@nxp.com
Changes in v5:
2/5
- updated the description of mboxes
- updated the description & items for mbox-names.
- updated the description of memory-region
- move "additional properties: false" after allOf block.
- removed other example except one.
4/5
- Corrected the indentation in Kconfig.
- info members:mbox_tx_name & mbox_rx_name, are replaced with macros.
5/5
- Replaced "for secure enclaves", with "for secure enclaves"
- Replaced "user space" with "userspace".
- End the line "[include]<linux/firmware/imx/ele_mu_ioctl.h>" with a period.
Reference:
- Link to v4: https://lore.kernel.org/r/20240705-imx-se-if-v4-0-52d000e18a1d@nxp.com
Changes in v4:
1/5
a. Removed - from EdgeLock Enclave.
b. Removed , after "Each of the above feature,"
c. replace "can exists" with "can exist".
d.
-messaging units(MU) per SE. Each co-existing 'se' can have one or multiple exclusive
-MU(s), dedicated to itself. None of the MU is shared between two SEs.
+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 Linux mailbox driver.
e.
-All those SE interfaces 'se-if' that is/are dedicated to a particular SE, will be
-enumerated and provisioned under the very single 'SE' node.
+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").
f. Removed ",". Replaced for "Each 'se-if'," with "Each se-if'.
g. removed ","
- This layer is responsible for ensuring the communication protocol, that is defined
+ This layer is responsible for ensuring the communication protocol that is defined
h. removed "-"
- - FW can handle one command-message at a time.
+ - FW can handle one command message at a time.
i.
- Using these multiple device contexts, that are getting multiplexed over a single MU,
- user-space 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 uses the above defined service layer API(s) to communicate with
+ 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.
j. Uppercase for word "Linux".
2/5
a. Rephrased the description to remove list of phandles.
b. Moved required before allOf:
+required:
+ - compatible
+ - reg
+ - mboxes
+ - mbox-names
+
+additionalProperties: false
+
allOf:
c. replaced not: required: with properties: <property-name>: false.
# memory-region
- not:
- required:
- - memory-region
+ properties:
+ memory-region: false
# sram
- else:
- not:
- required:
- - sram
d. Reduced examples. keeping example of i.MX95.
e. node-name is changed to "firmware@<hex>"
3/5
- node name changed to "firmware@<hex>".
4/5
- used sizeof(*s_info)
- return early, rather than doing goto exit, in ele_get_info().
- Use upper_32_bits() and lower_32_bits()
- use rx_msg here instead of priv->rx_msg
- Moved the status check to validate_rsp_hdr. Rename the function to "se_val_rsp_hdr_n_status"
- typecasting removed header = (struct se_msg_hdr *) msg;
- Converted the API name with prefix imx_ele_* or imx_se_*, to ele_* and se_*, respectively.
- Removed the functions definition & declaration for: free_phybuf_mem_pool() & get_phybuf_mem_pool()
- removed the mbox_free_channel() calls from clean-up.
- Flag "priv->flags" is removed.
- Converted the int se_if_probe_cleanup() to void se_if_probe_cleanup().
- Replaced NULL initialization of structure members: priv->cmd_receiver_dev & priv->waiting_rsp_dev , with comments.
- Removed the function's declaration get_phy_buf_mem_pool1
5/5
Changes to Documentation/ABI/testing/se-cdev.
a. Removed "-" from "secure-enclave" and "file-descriptor".
b. Removed "-" from "shared-library"
c. Replaced "get" with "getting".
d. Added description for the new IOCTL "send command and receive command response"
e. Replaced "wakeup_intruptible" with "wait_event_interruptible"
f. Removed ";"
g. Removd "," from "mailbox_lock,"
h. Replaced "free" with "frees"
i. In mailbox callback function, checking the buffer size before
copying.
Reference:
- Link to v3: https://lore.kernel.org/r/20240617-imx-se-if-v3-0-a7d28dea5c4a@nxp.com
Changes in v3:
5/5:
- Initialize tx_msg with NULL.
- memdup_user() returns an error pointer, not NULL. correct it by adding check for err_ptr.
- new IOCTL is added to send & recieve the message.
- replaced the while loop till list is empty, with list_for_each_entry.
- replaced __list_del_entry, with list_del.
- Removed the dev_err message from copy to user.
- Removed the casting of void *.
- corrected the typcasting in copy to user.
- removed un-necessary goto statement.
- Removed dead code for clean-up of memory.
- Removed un-mapping of secured memory
- Passing se_if_priv structure to init_device_context.
- Updated the below check to replace io.length with round_up(io.length).
if (shared_mem->size < shared_mem->pos|| io.length >= shared_mem->size - shared_mem->pos)
- Created a function to cleanup the list of shared memory buffers.
- Used list_for_each_entry_safe(). created a separate functions: se_dev_ctx_cpy_out_data() & se_dev_ctx_shared_mem_cleanup()
4/5
- Changed the compatible string to replace "-ele", to "-se".
- Declaration of imx_se_node_info, is done as const in the whole file
- Remove the unused macros from ele_base_msg.h
- Remove the function declaration get_phy_buf_mem_pool1, from the header file.
- Replace the use of dmam_alloc_coherent to dma_alloc_coherent
- Check for function pointer, before calling the fucntion pointer in imx_fetch_se_soc_info
- Removed the unused flag for SE_MU_IO_FLAGS_USE_SEC_MEM.
- Removed the unused macros WORD_SZ
- instead of struct device *dev, struct se_if_priv *priv, is used as argument to the funtions:se_save_imem_state, se_restore_imem_state, imx_fetch_se_soc_info
- Removed ret from validate_rsp_hdr.
- changed the prefix of the funtion: plat_add_msg_crc and plat_fill_cmd_msg_hdr.
- indentation correction for info structures.
- remove the check for priv not null from se_if_probe_cleanup
- Removed the casting of void *.
- se_load_firmware function is corrected for not freeing the buffer when allocation fails.
- Checking if get_imx_se_node_info() can return NULL, in se_if_probe()
- imem.size has type u32. return value from se_save_imem_state() will be assigned to imem.size in case of success only.
- removed the flag un-setting in case of failure. priv->flags &= (~RESERVED_DMA_POOL);
- removed the function call for devm_of_platform_populate(dev);
- Checking for not-NULL, before calling the funtion pointer se_fetch_soc_info.
- Removed the checking for reserved memory flag, before freeing up the reserved memory, in se_probe_if_cleanup.
3/5
- Changed the compatible string to replace "-ele", to "-se".
2/5
- to fix the warning error, replaced the "-ele" & "-v2x" in compatible string, to "-se".
- Added an example for ele@0 for compatible string "fsl,imx95-se"
Reference
- Link to v2: https://lore.kernel.org/r/20240523-imx-se-if-v2-0-5a6fd189a539@nxp.com
Changes in v2:
4/4
- Split this patch into two: 1. base driver & 2. Miscdev
- Initialize the return variable "err" as 0, before calling 'return err', in the file ele_common.c
- Fix the usage of un-iniitialized pointer variable, by initializing them with NULL, in ele_base_msg.c.
- Fix initializing the ret variable, to return the correct error code in case of issue.
- replaced dmam_alloc_coherent with dma_alloc_coherent.
- Replace the use of ELE_GET_INFO_READ_SZ, with sizeof(soc_info).
- Replaced -1 with -EPERM
- Removed the safety check on func-input param, in ele_get_info().
- fix the assigning data[1] with lower 32 address, rather than zero, for ele_fw_authenticate API.
- Correctly initializing the function's return error code, for file ele_base_msg.c.
- replaced 'return' with 'goto'.
- Use length in bytes.
- Corrected the structure se_msg_hdr.
- Moved setting of rx_msg to priv, into the function imx_ele_msg_send_rcv
- Will add lockdep_assert_held, to receive path, in v2.
- corrected the spacing at "ret = validate_rsp_hdr"
- FIELD_GET() used for RES_STATUS
- Re-write the structure soc_info, matching the information provided in response to this api.
- The "|" goes to the end of the previous line.
- Moved the locking and unlocking of the command lock to the caller of the function.
- removed the safety check for device private data.
- Structure memory reference, used to read message header.
- In the interrupt call back function, remove assigning waiting_rsp_dev to NULL, in case of response message rcv from FW.
- do while removed.
- replaced BIT(1) for RESERVED_DMA_POOL, to BIT(0)
- The backslash is removed while assigning the file name with absolute path to structure variable.fw_name_in_rfs =.
- Update the 'if' condition by removing "idx < 0".
- mbox_request_channel_byname() uses a "char" for the name not a u8. Corrected.
- devm managed resources, are not cleaned now, in function se_probe_if_cleanup
- Used dev_err_probe().
- Used %pe to print error string.
- remove "__maybe_unused" for "struct platform_device *enum_plat_dev __maybe_unused;"
- used FIELD_GET(), for RES_STATUS. Removed the use of MSG_TAG, MSG_COMMAND, MSG_SIZE, MSG_VER.
- Depricated the used of member of struct se_if_priv, bool no_dev_ctx_used;
- Moved the text explaing the synchronization logic via mutexes, from patch 1/4 to se_ctrl.h.
- removed the type casting of info_list = (struct imx_se_node_info_list *) device_get_match_data(dev->parent);
- Used static variable priv->soc_rev in the se_ctrl.c, replaced the following condition: if (info_list->soc_rev) to if (priv->soc_rev) for checking if this flow is already executed or not.
- imx_fetch_soc_info will return failure if the get_info function fails.
- Removed devm_free from imx_fetch_soc_info too.
3/3
- Made changes to move all the properties to parent node, without any child node.
2/4
- Use Hex pattern string.
- Move the properties to parent node, with no child node.
- Add i.MX95-ele to compatible nodes to fix the warning "/example-2/v2x: failed to match any schema with compatible: ['fsl,imx95-v2x']"
1/1
- Corrected the spelling from creats to creates.
- drop the braces around the plural 's' for interfaces
- written se in upper case SE.
- Replace "multiple message(s)" with messages.
- Removed too much details about locks.
Testing
- make CHECK_DTBS=y freescale/imx8ulp-evk.dtb;
- make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,imx-se.yaml
- make C=1 CHECK=scripts/coccicheck drivers/firmware/imx/*.* W=1 > r.txt
- ./scripts/checkpatch.pl --git <>..HEAD
- Tested the Image and .dtb, on the i.MX8ULP.
Reference
- Link to v1: https://lore.kernel.org/r/20240510-imx-se-if-v1-0-27c5a674916d@nxp.com
---
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
Documentation/ABI/testing/se-cdev | 43 +
.../devicetree/bindings/firmware/fsl,imx-se.yaml | 91 ++
.../driver-api/firmware/other_interfaces.rst | 131 +++
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 12 +-
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 11 +-
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 | 354 ++++++
drivers/firmware/imx/ele_common.h | 49 +
drivers/firmware/imx/se_ctrl.c | 1145 ++++++++++++++++++++
drivers/firmware/imx/se_ctrl.h | 128 +++
include/linux/firmware/imx/se_api.h | 14 +
include/uapi/linux/se_ioctl.h | 97 ++
15 files changed, 2451 insertions(+), 3 deletions(-)
---
base-commit: 07e27ad16399afcd693be20211b0dfae63e0615f
change-id: 20240507-imx-se-if-a40055093dc6
Best regards,
--
Pankaj Gupta <pankaj.gupta@nxp.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* [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
end of thread, other threads:[~2025-11-17 5:38 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 ` [PATCH v19 3/7] firmware: imx: add driver for NXP EdgeLock Enclave Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 4/7] firmware: imx: device context dedicated to priv Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 5/7] firmware: drivers: imx: adds miscdev Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 6/7] arm64: dts: imx8ulp: add secure enclave node Pankaj Gupta
2025-09-26 21:09 ` [PATCH v19 7/7] arm64: dts: imx8ulp-evk: add reserved memory property 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
2025-10-27 6:43 ` [EXT] " Pankaj Gupta
2025-11-03 19:08 ` Marco Felsch
2025-11-07 6:57 ` Pankaj Gupta
2025-11-11 13:14 ` Marco Felsch
2025-11-12 11:38 ` Pankaj Gupta
2025-11-12 15:05 ` Marco Felsch
2025-11-17 5:38 ` Pankaj Gupta
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).