Hello,
When trying to generate a persistent key in the ELE's Key Store on i.MX93. I run into the following error:
```
Getting device info
SoC ID : 0x9300
SoC Rev : 0xa100
LMDA val: 0x10
Creating a Key Store (0xabcd/0x1234)
Opening the Key Management Service
Going to try and generate a persistent key
SAB Error: SAB CMD [0x42] Resp [0x529] - Unknown error code
```
The code is mostly taken from https://github.com/nxp-imx/imx-secure-enclave/blob/lf-6.6.23_2.0.0/test/hsm/hsm_test.c#L256.
However, I encounter the exact same failure when trying to use the OPTEE test TA: https://github.com/nxp-imx/imx-optee-os/blob/lf-6.12.34_2.1.0/core/pta/imx/ele_test.c#L61
Although `imx-secure-enclave` reports an unknown error code (0x529), the error is actually `HSM_FATAL_FAILURE` with a rating of `HSM_NVM_ERROR`.
This is consistent with the fact that only generating persistent keys fails: generating transient keys works fine.
My question is therefore: why is the ELE complaining of an NVM error?
Is there a step I am missing to ensure NVM support in the ELE?
已解决! 转到解答。
Hello,
We have seen this kind of issue from previous experience, this one is usually seen when the nvm_daemon service is not started. After start nvm_daemon service, the keystore should be opened successfully.
You can try "ps -ef|grep nvm" to confirm if the nvm daemon is running in backend.
Best regards/Saludos,
Aldo.
Hello,
We have seen this kind of issue from previous experience, this one is usually seen when the nvm_daemon service is not started. After start nvm_daemon service, the keystore should be opened successfully.
You can try "ps -ef|grep nvm" to confirm if the nvm daemon is running in backend.
Best regards/Saludos,
Aldo.
Hello Aldo,
thank you so much for your help, this was indeed the issue!
For anyone wondering, nvm_daemon is a systemd service that is part of imx-secure-enclave, the userspace library for the ELE.
The service seems to not be automatically started by default.
From what I could tell from Chapter3 of the AN14105 Application Note ("Understanding SECO Secure Storage and Non-Volatile Memory Management"), the reason for this is, that the ELE itself does not have any non-volatile memory and instead relies on the NVM manager to store the wrapped keys to non-volatile memory.
In our case, this NVM manager is nvm_daemon.
That Application Note applies to SECO, but I'm going out on a limb an assuming that similar if not identical concepts apply to the ELE.