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]
Date:   Thu, 25 May 2023 00:01:50 +0000
From:   Peng Fan <peng.fan@....com>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        "Peng Fan (OSS)" <peng.fan@....nxp.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>
CC:     "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH V3] soc: imx: support i.MX93 soc device

> 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

It is 64bits. The RM maybe wrong.

> reference manual, which mentions a "UNIQUE_ID[127:64]" at offset 0xe00 -
> 0xe10 (i.e. bank 40, words 0 and 1).

Which chatper?
> 
> 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?

RM should be wrong. UID is in Bank 0.

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

Just as what the driver indicates, UID is at register address 0x420 and 0x430.

For bank 0x40, I could not reveal information if RM or Secure RM not say
something.

You could raise tickets in community.nxp.com to ask people follow up
on RM issue or else.

Thanks,
Peng.

> 
> Rasmus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ