linux-kernel - Re: [PATCH 1/2] mtd: spi-nor: winbond: Add support for w25q01jv

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] [day] [month] [year] [list]

Message-ID: <87a5btslfl.fsf@bootlin.com>
Date: Tue, 14 Jan 2025 12:07:42 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>,  Michael Walle
 <mwalle@...nel.org>,  Richard Weinberger <richard@....at>,  Vignesh
 Raghavendra <vigneshr@...com>,  Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>,  Steam Lin <STLin2@...bond.com>,
  linux-mtd@...ts.infradead.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mtd: spi-nor: winbond: Add support for w25q01jv

Hello Pratyush,

>> Winbond chips (maybe this is a shared capability?) accepts another
>> command, "Write Enable for Volatile Status Register (50h)", which
>> specifically change the status register bits to use the volatile method.
>>
>> Hence, if the only situation we want to solve is the status register
>> access, then we may just enable this command (this is the third solution
>> I tried to explain in the commit log), but if we think there are other
>> racy situations, this approach is not complete and we must fallback to
>> one of the approaches listed above.
>
> I am not quite sure how you fix the write-enable-being-racy bug with
> your patch. If you look at the code, spi_nor_write_enable() only calls
> the write enable command (06h), and does not call
> spi_nor_wait_till_ready() after that. After the write enable, it
> immediately executes the program or erase operation. So you never
> actually wait for all dies to be ready after a write enable.

I will double check but my understanding is that the *status register*
write is racy, not the spi_nor_write_enable().

> You can see an example in spi_nor_write(). It does:
>
>     spi_nor_write_enable() -> spi_nor_write_data() ->
>     spi_nor_wait_till_ready()

What is racy is: act on all dies then check the status of a single die.

> Do you have a consistent reproducer for the race? If so, does the patch
> actually somehow make the race go away? If so, I would be curious to
> know why.

Not with Linux, it is a problem that has been (consistently) observed
using an rtos. It's been analysed so we know what the issue is and we
want to make sure this cannot happen using Linux.

Thanks,
Miquèl