On 4/27/26 11:15 AM, Mathieu Othacehe wrote:
Hello Mathieu,
If you do want to expose the fuses via SMC , then the fuse region has to be
secure only , so only TFA can access it . TFA can then decide which exact fuse
the user can or can not read or program, on a single fuse granularity.
By default, non-secure user should be able to read some select fuses (IDs),
program no fuses. User should have the ability to expose some select fuses as
programmable, for manufacturing purposes.
Mathieu, which fuses exactly do you plan to program ?
I plan to program all fuses (enable secureboot, ROT hash, user
encryption keys) using U-Boot directly or U-Boot + TF-A during
manufacturing.
I then see two possibilities:
1. During manufacturing, use a specific TF-A that allows fusing from the
non-secure world (with SYS_SLVACCCTL7 register). Fuse directly
everything from U-Boot, using the patch under review. Then, flash the
regular, default TF-A that does not allow fusing from the non-secure
world.
2. During manufacturing, use a specific TF-A that allows, via SMC,
fusing everything from the non-secure world. Write a new U-Boot driver
that performs fusing through SMC. Use it to fuse everything from U-Boot
during manufacturing. Then, flash the regular, default TF-A that only
allows specific ID fuse read via SMC.
Both options require a specific TF-A during manufacturing. The only real
difference to me is that with option 2, we can allow ID fuse read from
U-Boot via SMC during regular use.
This difference is in fact a bit more important.
I agree that in both cases, it would be necessary to have a TFA capable
of programming the fuses, with one or the other mechanisms.
It is possible to expose the fuse block as read-only to U-Boot/Linux in
either case, but this may be undesired. It may be undesired to expose
all fuses to U-Boot/Linux, instead, it may be desired to expose only a
subset of fuses to U-Boot/Linux and prevent U-Boot/Linux from even
reading other fuses.
This is what I see as a benefit of option 2 -- it is possible to limit
which fuses can be accessed from U-Boot/Linux with single fuse
granularity. This is not possible with option 1.
But please look at prior art if/when implementing option 2 and learn
from their mistakes, Linux drivers/nvmem/imx-ocotp-scu.c is for MX8Q SCU
which is old and odd so ideally avoid that as an example,
drivers/nvmem/stm32-romem.c is I think limited to programming only full
32bit words (?) and does not handle single-fuse granularity. It would
also be good to design the SMC ABI in a way that maps easily to Linux
NVMEM API and in a way that is generic, so others could reuse it (if
possible) and reuse the (generic SMC fuse ABI) driver.
