linux-kernel - Re: [PATCH 16/19] mtd: spi-nor: Add steps for testing locking 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: <878qg2apsl.fsf@bootlin.com>
Date: Wed, 19 Nov 2025 18:35:38 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Michael Walle" <mwalle@...nel.org>
Cc: "Tudor Ambarus" <tudor.ambarus@...aro.org>,  "Pratyush Yadav"
 <pratyush@...nel.org>,  "Richard Weinberger" <richard@....at>,  "Vignesh
 Raghavendra" <vigneshr@...com>,  "Jonathan Corbet" <corbet@....net>,
  "Sean Anderson" <sean.anderson@...ux.dev>,  "Thomas Petazzoni"
 <thomas.petazzoni@...tlin.com>,  "Steam Lin" <STLin2@...bond.com>,
  <linux-mtd@...ts.infradead.org>,  <linux-kernel@...r.kernel.org>,
  <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 16/19] mtd: spi-nor: Add steps for testing locking support

>> 5) If your flash supports locking, please got through the following test
>>    procedure to make sure it correctly behaves.
>>
>>    Warning: These tests may hard lock your device! Make sure:
>>    - The device is not hard locked already (#WP strapped to low and
>>      SR_SRWD bit set)
>>    - If you have a #WP pin, you may want to set `no-wp` in your DT for
>>      the time of the test, to only make use of software protection.
>
> Yes that is much better. BTW, I've never seen "#signal" but only
> SIG#, nSIG, SIGn or /SIG, maybe I haven't paid too much attention.

Ah, right. I'm fine either ways. I'll look for occurrences and use one
of your suggestions.

>> Please amend this text if you still think it is missing his goal.
>
> What about
>
>     - If you have a WPn pin, you may want to set `no-wp` in your DT for
>       the time of the test, to only make use of software protection.
>       Otherwise, clearing the locking state depends on the WPn
>       signal and if it is tied to low, the flash will be permanently
>       locked.

Yep, I'll use that.

>>>> +    root@1:~# flash_lock -u /dev/mtd0
>>>> +    root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two
>>>> +    root@1:~# show_sectors
>>>> +    software locked sectors
>>>> +     region (in hex)   | status   | #blocks
>>>> +     ------------------+----------+--------
>>>> +     00000000-03fdffff | unlocked | 1022
>>>> +     03fe0000-03ffffff |   locked | 2
>>>> +    root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one
>>>
>>> huh? shouldn't that be 1 * $bs?
>>
>> I don't think so:
>> - first we lock the last two blocks (offset: size - 2 blocks, length: 2
>>   blocks)
>> - then we unlock the penultimate block so that only the last block
>>   remains locked (offset: size - 2 blocks, length 1).
>
> Yes you're correct. I've read the -u for a -l (and somehow assumed
> a complete unlock in between).

You cannot imagine how many times this happened to me while
writing/testing/documenting all this :-)

Thanks,
Miquèl