linux-kernel - Re: [PATCH V4 1/2] soc: imx: Correct i.MX8MP 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 for Android: free password hash cracker in your pocket

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

Message-ID: <04a3e224-3f06-47e9-54ca-44a0c4d5759c@prevas.dk>
Date:   Tue, 30 May 2023 10:06:13 +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 V4 1/2] soc: imx: Correct i.MX8MP soc device

On 29/05/2023 05.37, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@....com>
> 
> i.MX8MP UID is actually 128bits and partitioned into two parts, with 1st
> 64bits at 0x410 and 0x420, with 2nd 64bits at 0xE00 and 0xE10.
> 
> So introduce soc_uid_h for the higher 64bits

Interestingly, reaching out to our NXP sales rep asking for
clarification resulted in:

  On i.MX 8MP Unique ID is 64 bits. Please see here:

https://github.com/nxp-imx/uboot-imx/blob/lf_v2022.04/arch/arm/mach-imx/imx8m/soc.c#L752

So could you guys (and here I'm referring to everybody with an @nxp.com
email) internally _please_ talk to each other and figure out what's what.

And, again assuming that the UID is really 128 bits, nobody has yet
answered why the upper 64 bits are not locked down, nor what would/could
happen if the end user/customer modifies those bits.

> Fixes: 18f662a73862 ("soc: imx: Add i.MX8MP SoC driver support")
> Reported-by: Rasmus Villemoes <rasmus.villemoes@...vas.dk>

That's true.

> Closes: https://lore.kernel.org/all/fe5e2b36-6a8e-656c-a4a6-13a47f4871af@prevas.dk/

Not at all. We (anybody outside nxp.com, and from what I can tell,
probably quite a few people inside) still lack a complete explanation
for this whole mess - why does the RM say one thing, which gets repeated
by NXP TechSupport in a community forum, while a sales representative
asserts that the current code (in both mainline and downstream linux and
u-boot) is correct, and now you claim that in fact the current code is
not correct.

Rasmus