U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Othacehe <othacehe@gnu.org>
To: Marek Vasut <marek.vasut@mailbox.org>
Cc: Biju Das <biju.das.jz@bp.renesas.com>,
	 Tom Rini <trini@konsulko.com>, Paul Barker <paul@pbarker.dev>,
	 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>,
	 geert <geert@linux-m68k.org>,
	 Michael Allport <michael.allport.wm@renesas.com>,
	 Marcel Medvec <marcel.medvec.uj@bp.renesas.com>,
	 Chris Paterson <Chris.Paterson2@renesas.com>,
	 "u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: Re: [PATCH v3] misc: Add RZG2L OTP support
Date: Mon, 27 Apr 2026 11:15:04 +0200	[thread overview]
Message-ID: <87cxzkn4rr.fsf@gnu.org> (raw)
In-Reply-To: <9e1786f1-2607-473e-8ed1-dc29c40ec470@mailbox.org>


Hello Marek,

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

What do you think?

Thanks,

Mathieu

  parent reply	other threads:[~2026-04-27  9:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-22  9:36 [PATCH v3] misc: Add RZG2L OTP support Mathieu Othacehe
     [not found] ` <c9af344e-6342-41a4-9ca3-a683691fcd52@mailbox.org>
     [not found]   ` <TYCPR01MB11332159D47D6E4ED78598B1A862A2@TYCPR01MB11332.jpnprd01.prod.outlook.com>
2026-04-23 12:41     ` Mathieu Othacehe
     [not found]     ` <7ac4e375-859c-43a9-9cf2-fc44505e2c30@mailbox.org>
     [not found]       ` <TYWPR01MB11343A62FB03012A458C1B1DC862A2@TYWPR01MB11343.jpnprd01.prod.outlook.com>
     [not found]         ` <TYWPR01MB11343DA55762DB428EA42B211862A2@TYWPR01MB11343.jpnprd01.prod.outlook.com>
     [not found]           ` <9e1786f1-2607-473e-8ed1-dc29c40ec470@mailbox.org>
2026-04-27  9:15             ` Mathieu Othacehe [this message]
2026-05-04 23:41               ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cxzkn4rr.fsf@gnu.org \
    --to=othacehe@gnu.org \
    --cc=Chris.Paterson2@renesas.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=geert@linux-m68k.org \
    --cc=iwamatsu@nigauri.org \
    --cc=marcel.medvec.uj@bp.renesas.com \
    --cc=marek.vasut@mailbox.org \
    --cc=michael.allport.wm@renesas.com \
    --cc=paul@pbarker.dev \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox