Hello @RiBe_Act,
Upon further investigation, the behavior you see is due to missing entries on the meta-toradex-security layer.
Originally, both 0071 and 0072 modules were planned to use General Purpose (GP) SoCs, but this was changed since V1.1B.
Therefore, these modules are fully capable of secure boot.
I apologize for the delay in realizing such issue.
To get this solved in your build, you just need to add the entries as in the following pull-request: tdx-signed-k3: Add entries for HS-SE tiboot3 on verdin-am62 by brunoaamello · Pull Request #101 · toradex/meta-toradex-security · GitHub
I think these entries will be in a different file for you as you are using a slightly older version of Torizon OS as a base.
Best Regards,
Bruno
Hi Bruno,
After this addition i am getting the expected booting failure, ill test with the fuse burning and let you know the results, but i expect smooth sailing from here.
Thank you for the support during this search.
Regarding the pull request, is this (when merged) included in the default setup for the crops container or not yet, if not please add a note on the meta page about this issue.
Hello @RiBe_Act,
Thanks for the update, it is good to know you got the expected behavior.
When the pull-request is merged, it will be available on the latest version of the meta-toradex-security layer.
By default the crops container may not necessarily get the latest layer, it will depend on the branch and manifest configuration.
With the configuration you have, after it is merged, in the following monthly or quarterly release it will be available.
Best Regards,
Bruno
Hi Bruno,
This morning i tested the fuse burning procedure and this now works as expected.
The module initially didn’t boot (as expected) after the image was flashed and after i set the matching fuses it did correctly boot.
One thing i still noticed is that the keys used in the booting procedure are still the dev keys however. When i look at the meta data layer page for fit image signing it states that the variables for am62 are set in the file “tdx-signed-fit-image.inc” and when i look at those they match the key settings which are shown in the boot log of the device. So i dont understand how these are to be linked to the custMpk keys as shown in you demo boot log. Am i missing a step here perhaps?
tdx-signed-fit-image.inc file:
boot log module:
Kind regards,
Richard
Hello @RiBe_Act,
Upon further investigation, my initial build was made with an older layer version.
This version was missing the following commit: tdx-signed-fit-image: override signing parameters from TI · toradex/meta-toradex-security@e7009cf · GitHub
With this commit you get the FIT image to be signed with a dev key, which is generated automatically.
Without it you get the behavior I showed initially where the FIT image is signed with the custMpk key.
By changing the variables added on this commit, you can configure a custom key that you manage to sign your FIT image.
Discussing this internally, it turns out this was an intended change.
The reason for this is that we use a multi-key approach, meaning that for each step in the chain of trust we use a different key to sign the artifacts.
This is done for security reasons:
If one key is compromised, only a part of the chain is affected. This can make revocation and re-signing with a new key more manageable and contained.
Best Regards,
Bruno
Hi Bruno,
Thank you for the message, after reading all the initial documentation this was also my understanding (that the custMpk keys are used for the first step of the secure boot sequence and that the dev keys are purposely generated for the second step of the verification process).
Thank you for this whole process and the research/answers for my questions.
Kind regards,
Richard
1 Like
Hello @bruno.tx @jeremias.tx ,
I’m using Mallow Carrier Board 1.1C with Verdin AM62D 1GB IT and I have a similar issue where the VPP pin is not connected to the Mallow board. I’m wondering if you have any plans to address this in future hardware revisions?
Best Regards,
Jonathan
Hello @Silicon14,
This has been addressed in V1.2 of all Verdin AM62 modules.
In V1.2, a dedicated LDO with enable pin for supplying VPP voltage which is used for fusing the OTP memory of AM62 SoC was added.
If you have other questions or face any issues with this procedure, please start another topic here on the community so we can support you with this.
Best Regards,
Bruno
