topic Re: OTP and Shadow registers - Super Root Keys for Secure Boot in i.MX Processors

OTP and Shadow registers - Super Root Keys for Secure Boot

satyadamarla — Fri, 24 Feb 2017 07:54:38 GMT

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:

The Kernel and u-boot loader donot have any HAB events.
This means the original values are still saved but they are not anymore readable.
The iMX6 Reference manual talks about Shadow Registers.

Questions:

What are Shadow Registers? Why are they used here? What happens if they aren't used here?
Can I lock my device now? If I lock it will my signatures still work?
Can anyone please give a logical explanation here about why these OTP registers rewriting works at Linux level.

Greets,

Satya

Re: OTP and Shadow registers - Super Root Keys for Secure Boot

Yuri — Wed, 01 Mar 2017 07:03:00 GMT

Hello,

Please look at my comments below.

> 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.

> 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 >

> 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!

Re: OTP and Shadow registers - Super Root Keys for Secure Boot

satyadamarla — Mon, 06 Mar 2017 13:42:41 GMT

Hello Yuri,

Thank for the time to reply. I have a better understanding of OTP now.

Is there a way to lock (like a hardware lock) so that no one meddle with the OTP.
When chip security is turned on (SEC_CONFIG), can one still meddle with OTP?

Greets,

Satya