linux-kernel - Re: [PATCH V3] soc: imx: support i.MX93 soc device

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <33d57180-aa13-4178-86e1-c4cf6ef29a6e@prevas.dk>
Date:   Wed, 24 May 2023 15:30:01 +0200
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     "Peng Fan (OSS)" <peng.fan@....nxp.com>, shawnguo@...nel.org,
        s.hauer@...gutronix.de
Cc:     kernel@...gutronix.de, festevam@...il.com, linux-imx@....com,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Peng Fan <peng.fan@....com>
Subject: Re: [PATCH V3] soc: imx: support i.MX93 soc device

On 15/05/2023 08.37, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@....com>
> 
> i.MX93 Device Unique ID(UID) is in eFuse that could be read through
> OCOTP Fuse Shadow Block. i.MX93 UID is 128 bits long, so introduce
> soc_uid_high to indicate the higher 64bits.

So apparently, the imx8mp also has 128 bits, at least according to the
reference manual, which mentions a "UNIQUE_ID[127:64]" at offset 0xe00 -
0xe10 (i.e. bank 40, words 0 and 1).

However, no further mention of these upper bits can be found anywhere in
the RM, or in linux or u-boot, mainline or downstream NXP. Furthermore,
quick experiments on both an imx8mp-evk and a custom imx8mp board
reveals that those words are not locked down (they do seem to have some
contents from the factory, but I can still set more bits in them).

Could someone from NXP please explain what exactly bank 40, words 0 and
1, on imx8mp are for? What do their initial value mean, why are they not
locked down, and why does the RM indicate that they should be part of a
unique_id?

Also, assuming that the RM is just wrong (wouldn't be the first time;
the description of the lower 64 bits is also wonky in its own special
way), an obvious follow-up question is: Are the currently exposed
(lower) 64 bits unique among all imx8mp SOCs, i.e. does those 64 bits by
themselves actually work as a uid?

Rasmus