linux-kernel - Re: [PATCH 2/2] mtd: spi-nand: macronix: Add randomizer 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] [day] [month] [year] [list]

Message-ID: <874ithm1ol.fsf@bootlin.com>
Date: Fri, 05 Sep 2025 16:08:58 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Cheng Ming Lin <linchengming884@...il.com>
Cc: vigneshr@...com,  linux-mtd@...ts.infradead.org,
  linux-kernel@...r.kernel.org,  richard@....at,  alvinzhou@...c.com.tw,
  leoyu@...c.com.tw,  Cheng Ming Lin <chengminglin@...c.com.tw>
Subject: Re: [PATCH 2/2] mtd: spi-nand: macronix: Add randomizer support

Hello,

On 05/09/2025 at 09:14:40 +08, Cheng Ming Lin <linchengming884@...il.com> wrote:

> Hi Miquel,
>
> Miquel Raynal <miquel.raynal@...tlin.com> 於 2025年8月18日 週一 下午4:47寫道：
>>
>> Hi Chang Ming,
>>
>> On 11/08/2025 at 11:01:25 +08, Cheng Ming Lin <linchengming884@...il.com> wrote:
>>
>> > Hi Miquel,
>> >
>> > Miquel Raynal <miquel.raynal@...tlin.com> 於 2025年8月8日 週五 下午6:19寫道：
>> >>
>> >> On 08/08/2025 at 17:55:03 +08, Cheng Ming Lin <linchengming884@...il.com> wrote:
>> >>
>> >> > From: Cheng Ming Lin <chengminglin@...c.com.tw>
>> >> >
>> >> > Enable randomizer function by specific flowchart to set the default value
>> >> > of RANDEN to 1.
>> >> >
>> >> > Randomizer introduces two new DT properties for child nodes to configure
>> >> > the randomizer functionality and coverage options.
>> >> >  - mxic,enable-randomizer-otp: Specify whether to activate the randomizer
>> >> >                                feature.
>> >> >  - mxic,randopt: Define the randomizer area per page.
>> >>
>> >> Can we create a global NAND DT property for that? Enabling a randomizer
>> >> is quite a generic step.
>> >>
>> >> > The penalty of randomizer are subpage accesses prohibited and more time
>> >> > period is needed in program operation and entering deep power-down mode.
>> >> > i.e., tPROG 320us to 360us (randomizer enabled).
>> >>
>> >> Do you want to share what is the added value in terms of lifetime to
>> >> enable the randomizer, given the drawbacks which are significant?
>> >
>> > The randomizer mainly targets extremely unbalanced data patterns,
>> > which might potentially lead to data errors.
>> >
>> > Please refer to the attached document:
>> > https://www.mxic.com.tw/Lists/ApplicationNote/Attachments/2151/AN1051V1-The%20Introduction%20of%20Randomizer%20Feature%20on%20MX30xFxG28AD_MX35xFxG24AD.pdf
>>
>> Thanks for the link, it may be pointed with a "Link:" tag in your commit
>> to further justify this addition. However it is sparse on details. I
>> would be interested by more details, such as "how many 0s? how many
>> bitflips? how often/likely?"
>
> Thank you for your feedback. Unfortunately we do not have numerical
> data such as exact numbers of '0's, bitflip rates, or occurrence
> probabilities to share. Instead, I would like to refer to the JEDEC
> JESD22-A117E qualification standard, which provides guidance on
> retention and endurance testing.
>
> According to this document, there is no single data pattern that
> represents a universal worst-case across all failure mechanisms.
> Different mechanisms may stress programmed cells, erased cells, or
> cells influenced by adjacent states, and thus specific patterns such
> as fully programmed, checkerboard, or mostly erased are each only
> worst-case for certain designs or processes.
>
> Given that no fixed pattern can cover all cases, the use of a
> randomized data pattern is considered a practical mitigation
> strategy. A randomizer distributes stress more evenly across the
> device by scrambling incoming data before storage and restoring it
> on read. This helps reduce pattern-dependent degradation and can
> therefore improve long-term flash reliability.

Thanks for the details. I guess you can add a bit of them to your commit
log as well. I'll welcome a v2 with the previous comments addressed!

Thanks,
Miquèl