Locking fuse banks on IMX8MP

[jonifndef]

Hi,

I am burning some fuses with the help of the ocotp driver on my IMX8MP board. Among other things, I am burning the mac addresses (HW_OCOTP_MAC_ADDR0, HW_OCOTP_MAC_ADDR1, HW_OCOTP_MAC_ADDR2). I am opening the file exposed by the ocotp driver (for me it's located at /sys/bus/nvmem/devices/imx-ocotp0/nvmem) and writing data to it. It works fine, when rebooting the board the mac addresses are set. But now I want to lock these fuses, so no one can write another mac address to the board, or tamper with it in some way.

When reading the reference manual, under section 6.3.2.1.3, I can see that

"Shadow register bits can be overridden by software until the corresponding fuse lock bit for the region is set. When the lock shadow bit is set, the shadow registers for that lock region become write locked."

Then it is explained that

"In order to avoid "rogue" code performing erroneous writes to OTP, a special unlocking
sequence is required for writes to the fuse banks. To program fuse bank complete the
following steps:"

Here I am getting a bit lost. Maybe I misunderstand something about fuse writing, but my understanding has always been that once we flip a fuse bit, that bit is forever locked. I want to make sure that non-flipped bits (where we might have written zeroes for example) cannot be flipped. I don't want to have a way to unlock the fuse writing. So my questions are:

1. How can this be done for e.g. mac addresses?
2. Can it be done in userspace with the ocotp driver?


Thanks,
Jonas

[Manuel_Salas]

Hello @jonifndef 

I hope you are doing very well.

You can refer to the Security Reference Manual, there is described the MAC_ADDR_LOCK fuse.

• Lock - The controlled field cannot be read, burned, or overridden.

• Override Protect (OP) - The controlled field cannot overwrite the corresponding OCOTP shadow register content. The controlled field can sense or burn fuses, and read the corresponding OCOTP shadow register 

• Write Protect (WP) - The controlled field cannot burn a fuse. The controlled field can be sensed (fuse), read or overridden in the corresponding OCOTP shadow register.

• OP + WP - The controlled field cannot burn (fuses) or overwrite the corresponding OCOTP shadow register. The controlled field can only sense (fuses) or read the corresponding OCOTP shadow register.

Best regards,

Salas.

[jonifndef]

Thanks for the answer. When looking at these registers in the 6.3.5.1.1 section, it says that they are "read only":
"RO" in the far right corner

Can I write to there registers in some way despite this? Or am I looking at the wrong table?
Like I said in my previous post, my preferred way of accessing these is through the ocotp driver in linux userspace, writing to the nvmem file in sysfs. 

/Jonas

[Manuel_Salas]

Hello @jonifndef 

With nvmem driver you can see the MAC with command:

root@imx8mpevk:~# hexdump /sys/devices/platform/soc@0/30000000.bus/30350000.efuse/imx-ocotp0/nvmem 

0000000 a9eb ffaf aaff 0002 f7d8 296d 3000 1c11
0000010 4581 0002 0000 0100 007f 0000 0000 8800
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000040 bada bada bada bada bada bada bada bada
*
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0000080 0000 0000 0000 0000 0000 0000 0004 0000
0000090 0765 9f07 0004 0766 9f07 0004 0000 0000
00000a0 bada bada bada bada bada bada bada bada
*
00000c0 f672 b8ff 506f c061 f92b 55df 48d5 9552
00000d0 b347 d7ff 1239 8d8e f73a 19a6 3ef5 a09f
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 bada bada 0000 0000 0000 0000 bada bada
0000100 bada bada bada bada bada bada bada bada
*
0000250 bada bada bada bada bada bada 121b 0001
0000260 1100 0000 0000 a800 6919 f1e9 5364 1ecb
0000270 264d 00b6 0000 0000 0000 0000 0000 0000
0000280 25c9 dacf bd4e 46a7 0000 0000 0000 0000
0000290 0000 0000 0000 0000 0000 0000 0000 0000
*
00002d0 bada bada bada bada bada bada bada bada
*
00002f0 0801 5500 73a8 0001 201f d503 0000 0000
0000300 0000 0000 0000 0000 0000 0000 0000 0000
*
00005f0 0000 0000 0000 0000 0001 0001 5bb6 8002
0000600

Then confirm the MAC with:

root@imx8mpevk:~# ip a | grep eth
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:04:9f:07:07:65 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:04:9f:07:07:66 brd ff:ff:ff:ff:ff:ff

In the hexdump you  can see the address 0x90, there are both MAC address.

To write, please refer to the chapter 13.4 Examples to read/write the raw NVMEM file in user space of Linux User's Manual.

[jonifndef]

Thank you for sticking with me. I have written to the fuses just as described in Linux User's Manual. I can also verify the mac addresses by running hexdump on the nvmem file. The problem is that I want to lock these fuses completely, as described in my first post. 

The MAC_ADDR_LOCK fuse you suggested in your first answer is listed as read-only in the reference manual (see my attached image in previous answer). But in section 6.3.2.1.3 of the reference manual, it is stated that:

"Shadow register bits can be overridden by software until the corresponding fuse lock bit for the region is set. When the lock shadow bit is set, the shadow registers for that lock region become write locked."

So my question is simply, how can I set the corresponding fuse lock bit for this region (and others) when the MAC_ADDR_LOCK fuse is read-only? Or is the fuse lock bit set already after having written to the nvmem file as described in the Linux User's Manual?

[jonifndef · Accepted solution]

So, for anyone finding this thread and still haven't tried, the HW_OCOTP_LOCK1 register, listed as read-only in the reference manual, was indeed writable. So I wrote to it from user space, using the syfs file /sys/bus/nvmem/devices/imx-ocotp0/nvmem exposed by the imx_octop driver. And everything seems to work, after a power cycle as well. 

Lesson: don't trust the manual...?