linux-kernel - Re: [PATCH v2 5/5] mtd: core: add OTP nvmem provider support

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: <f48661d2d54b37db395fb73af8b52359@walle.cc>
Date:   Fri, 02 Jul 2021 00:10:24 +0200
From:   Michael Walle <michael@...le.cc>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH v2 5/5] mtd: core: add OTP nvmem provider support

Hi Guenter,

Am 2021-07-01 23:34, schrieb Guenter Roeck:
> Hi,
> 
> On Sat, Apr 24, 2021 at 01:06:08PM +0200, Michael Walle wrote:
>> Flash OTP regions can already be read via user space. Some boards have
>> their serial number or MAC addresses stored in the OTP regions. Add
>> support for them being a (read-only) nvmem provider.
>> 
>> The API to read the OTP data is already in place. It distinguishes
>> between factory and user OTP, thus there are up to two different
>> providers.
>> 
>> Signed-off-by: Michael Walle <michael@...le.cc>
> 
> This patch causes a boot failure with one of my qemu tests.
> With the patch in place, the flash fails to instantiate.
> 
> [    1.156578] Creating 3 MTD partitions on "physmap-flash":
> [    1.157192] 0x000000000000-0x000000040000 : "U-Boot Bootloader"
> [    1.184632] 0x000000040000-0x000000060000 : "U-Boot Environment"
> [    1.201767] 0x000000060000-0x000000800000 : "Flash"
> [    1.222320] Deleting MTD partitions on "physmap-flash":
> [    1.222744] Deleting U-Boot Bootloader MTD partition
> [    1.303597] Deleting U-Boot Environment MTD partition
> [    1.368751] Deleting Flash MTD partition
> [    1.430619] physmap-flash: probe of physmap-flash failed with error 
> -61
> 
> -61 is -ENODATA.
> 
> Other boot tests with different flash chips can still boot.
> Reverting this patch (as well as the follow-up patches) fixes
> the problem.
> 
> I do not know if this is a problem with qemu or a problem with the
> patch, but, as I mentioned, other flash chips do still instantiate.
> 
> Do you have an idea what to look for when I try to track down the 
> problem ?

I'd start by looking at the return code of mtd_otp_size() because that
should be the only function which communicates with the flash at probe
time.

Can you share how to reproduce that problem? Like the qemu commandline
and involved images?

-michael