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?
Solved! Go to Solution.
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.
Hello,
Glad that it helped, and thank you for sharing more information about the topic this may be useful for anyone else that may be looking for something similar.
Best regards/Saludos,
Aldo.