Hello Everyone,
I made a strange observation and I am looking for a logical explanation.
Initially, I flashed the 4SRK onto the fuse bank 3 starting from words 0 to 7 at the u-boot level using the command fuse. I signed my multi-stage bootloader and kernel and they work like a charam. I didn't lock the device yet because I want to check if the Secure Chain actually works.
Incident/Accident:
There is a FSL-OTP driver in Linux Kernel (not bootloader u-boot). This driver mounts the information register content onto sys. I opened the first word HW_OCOTP_SRK0 and it's available there. This is 0xD1621DC9. I edited this expecting it never change and it got saved. I was surprised it has a new value. I rebooted my device, checked it at u-boot level using the fuse command and the new value is read instead of the old one.
=> fuse read 3 0
Reading bank 3:
Word 0x00000000: dbee7fc9
-------------------------------------------
cat /sys/fsl_otp/HW_OCOTP_SRK0
0xdbee7fc9
Observation:
Questions:
Greets,
Satya
Solved! Go to Solution.
Hello,
Please look at my comments below.
1.
> What are Shadow Registers? Why are they used here? What happens if they
> aren't used here?
The Shadow Registers may be considered as fuse’s cache; this allows to read and override
fuse values in shadow cache without affecting fuse elements.
2.
> Can I lock my device now? If I lock it will my signatures still work?
I do not think so. The i.MX6 OTP fuses can be blown once. It is not possible to
restore blown bits, but is is possible to write non-blown yet bits.
Note, “there is a known limitation about the verification of the SRK table in the ROM of
i.MX 6 Series devices. In these devices, the intent was to only verify the SRK table hash, when the
SRK fuse field was non-zero for Open configuration. However, for i.MX 6 Series in Open configuration,
the HAB always skips the verification of the SRK table, regardless of whether the SRK fuse field has
been provisioned or not. This means that it is necessary to ensure that the SRK field is correctly programmed,
prior to moving the i.MX 6 Series security configuration to Closed. It is highly recommended to use the srktool
included as part of the CST release. The byte ordering of the SRK table hash value should be correct to ensure
proper operation. Failing to follow the steps in provisioning the SRK hash eFuses correctly results in a device that
will not boot in Closed configuration."
Also, please look at Appendix A (SRK Revocation on i.MX 6 Series) of app note AN4581 "Secure Boot on
i.MX50, i.MX53, and i.MX 6 Series using HABv4", Rev. 1, 10/2015
< http://www.nxp.com/assets/documents/data/en/application-notes/AN4581.pdf >
3.
> Can anyone please give a logical explanation here about why these OTP
> registers rewriting works at Linux level.
The Linux fsl_otp driver provides the function to program fuses.
It is possible to write directly to shadow registers ; the values will not be programmed
to fuse if the corresponding operation flow is not performed.
Have a great day,
Yuri
------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer
button. Thank you!
Hello,
Please look at my comments below.
1.
> What are Shadow Registers? Why are they used here? What happens if they
> aren't used here?
The Shadow Registers may be considered as fuse’s cache; this allows to read and override
fuse values in shadow cache without affecting fuse elements.
2.
> Can I lock my device now? If I lock it will my signatures still work?
I do not think so. The i.MX6 OTP fuses can be blown once. It is not possible to
restore blown bits, but is is possible to write non-blown yet bits.
Note, “there is a known limitation about the verification of the SRK table in the ROM of
i.MX 6 Series devices. In these devices, the intent was to only verify the SRK table hash, when the
SRK fuse field was non-zero for Open configuration. However, for i.MX 6 Series in Open configuration,
the HAB always skips the verification of the SRK table, regardless of whether the SRK fuse field has
been provisioned or not. This means that it is necessary to ensure that the SRK field is correctly programmed,
prior to moving the i.MX 6 Series security configuration to Closed. It is highly recommended to use the srktool
included as part of the CST release. The byte ordering of the SRK table hash value should be correct to ensure
proper operation. Failing to follow the steps in provisioning the SRK hash eFuses correctly results in a device that
will not boot in Closed configuration."
Also, please look at Appendix A (SRK Revocation on i.MX 6 Series) of app note AN4581 "Secure Boot on
i.MX50, i.MX53, and i.MX 6 Series using HABv4", Rev. 1, 10/2015
< http://www.nxp.com/assets/documents/data/en/application-notes/AN4581.pdf >
3.
> Can anyone please give a logical explanation here about why these OTP
> registers rewriting works at Linux level.
The Linux fsl_otp driver provides the function to program fuses.
It is possible to write directly to shadow registers ; the values will not be programmed
to fuse if the corresponding operation flow is not performed.
Have a great day,
Yuri
------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer
button. Thank you!
Hello Yuri,
Thank for the time to reply. I have a better understanding of OTP now.
Greets,
Satya