linux-kernel - Re: [RFC PATCH 0/5] Add NVMEM driver for i.MX93 OTP access through ELE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <174b5a55-77ff-42bc-a043-82f3f391b8eb@kontron.de>
Date: Tue, 22 Apr 2025 09:33:40 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Peng Fan <peng.fan@....nxp.com>, Frieder Schrempf <frieder@...s.de>
Cc: Peng Fan <peng.fan@....com>, Pankaj Gupta <pankaj.gupta@....com>,
 linux-arm-kernel@...ts.infradead.org, Conor Dooley <conor+dt@...nel.org>,
 devicetree@...r.kernel.org, imx@...ts.linux.dev,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, linux-kernel@...r.kernel.org,
 Rob Herring <robh@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
 Shawn Guo <shawnguo@...nel.org>,
 Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Arnd Bergmann <arnd@...db.de>, Fabio Estevam <festevam@...il.com>,
 Frank Li <Frank.Li@....com>, Geert Uytterhoeven <geert+renesas@...der.be>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Rafał Miłecki <rafal@...ecki.pl>,
 Shengjiu Wang <shengjiu.wang@....com>, Shenwei Wang <shenwei.wang@....com>,
 Xu Yang <xu.yang_2@....com>,
 Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
Subject: Re: [RFC PATCH 0/5] Add NVMEM driver for i.MX93 OTP access through
 ELE

Hi Peng,

Am 22.04.25 um 08:30 schrieb Peng Fan:
> Hi Frieder,
> 
> On Wed, Apr 16, 2025 at 04:26:19PM +0200, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf@...tron.de>
>>
>> This depends on [1] for the support of the Edgelock Secure Enclave firmware
>> driver.
>>
>> There are at least two ways to access the OTP fuses on i.MX93:
>>
>> (1) through the FSB (fuseblock) registers
>> (2) through the ELE S400 API
>>
>> There currently is a NVMEM driver imx-ocotp-ele.c that (despite its name)
>> implements (1). As the FSB only provides limited access to the OTP registers
>> (read only) it's not sufficient for all use-cases.
>>
>> It seems like imx-ocotp-ele.c was intended to be extended later to implement
>> (1) and (2) deciding on a per-fuse-register basis which of both access methods
>> should be used.
>>
>> This has some downsides:
>>
>> * the driver gets convoluted and complex
>> * the driver decides which OTP registers are accessed in which way and therefore
>>  mixes read-only and read/write access
>>
>> Therefore I implemented a simple driver that uses the ELE S400 API only, as the
>> FSB access (1) doesn't provide any benefits except for that it doesn't depend
>> on the ELE firmware being available. This is used by us downstream.
>>
>> For the upstream solution I would like to have some feedback on how to move
>> on:
>>
>> 1. switch imx-ocotp-ele.c to use ELE API exclusively
>>   -> this will create a hard dependency on the ELE firmware/driver being available
>> 2. extend imx-ocotp-ele.c to use FSB and ELE API
>>   -> make the driver use ELE API for all registers if ELE firmware/driver is available
>> 3. create separate drivers as done in this RFC
> 
> Need to confirm ELE APIs supports all fuses. If yes, switching to using ELE API
> exclusively should be ok, no need to mix FSB and ELE API. And drop the current
> FSB usage

Ok, I already compared what fuse registers I can access via FSB and ELE.
The ELE seems to cover all registers that are available via FSB so that
shouldn't be a problem.

Still, after thinking a bit more about it, option 2 above seems like the
best way to go to me.

In case someone wants to use the system without the proprietary ELE
firmware, I'd like them to not run into the obstacle of loosing read
access to the OTPs. Especially as the Ethernet driver expects the NVMEM
cells for the MAC address to be available.

I know that the ELE firmware is currently somewhat mandatory as the
bootloader uses it, but I guess it would be possible and for some people
also desirable to have a system without it.

So what I would like to have is an optional DT property for the
imx-ocotp-ele.c driver to point to the secure enclave node. If the ELE
device is available at probe time, make the driver use the ELE API
exclusively. If not, fall back to the FSB API with read-only access.

If someone wants to avoid the ELE API altogether for whatever reason,
they could remove the link to the secure enclave node in their board DT.

Thanks
Frieder