linux-kernel - [PATCH 2/2] mtd: spi-nor: disable software protection for Winbond flash at startup (again)

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: <1be3216ae9a70f5c9914fd69042b13dc09a6c7cd.1463578354.git.mschiffer@universe-factory.net>
Date:	Wed, 18 May 2016 15:32:34 +0200
From:	Matthias Schiffer <mschiffer@...verse-factory.net>
To:	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Cc:	Felix Fietkau <nbd@....name>
Subject: [PATCH 2/2] mtd: spi-nor: disable software protection for Winbond flash at startup (again)

Support for unlocking Winbond flash had been originally added in c6fc217
("mtd: spi-nor: disable protection for Winbond flash at startup"), but was
reverted in 67b9bcd ("mtd: spi-nor: fix Spansion regressions (aliased with
Winbond)"), as some Spansion chips using the Winbond manufacturer ID
weren't working correctly with it.

The actual issue has been fixed meanwhile in 32321e9 ("mtd: spi-nor: wait
until lock/unlock operations are ready") and edf891e ("mtd: spi-nor: wait
for SR_WIP to clear on initial unlock"). After this fix, the Winbond flash
can be unlocked without causing havoc for Spansion chips.

We have verified that everything is working correctly on some Winbond chips
(like the w25q64, which is aliased with the Spansion s25fl064k) and
Spansion chips.

As an additional test, I also tried enabling the initial unlocking code for
the Spansion manufacturer ID. All tested Spansion flash chips showed the
same behaviour: without 32321e9 and edf891e, subsequent reads only returned
zeros (as reported by Felix Fietkau, leading to 67b9bcd), but with 32321e9
and edf891e, the chip continued to work correctly.

Cc: Felix Fietkau <nbd@....name>
Signed-off-by: Matthias Schiffer <mschiffer@...verse-factory.net>
---
 drivers/mtd/spi-nor/spi-nor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d681003..a834e66 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1306,6 +1306,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	    JEDEC_MFR(info) == SNOR_MFR_INTEL ||
 	    JEDEC_MFR(info) == SNOR_MFR_MACRONIX ||
 	    JEDEC_MFR(info) == SNOR_MFR_SST ||
+	    JEDEC_MFR(info) == SNOR_MFR_WINBOND ||
 	    info->flags & SPI_NOR_HAS_LOCK) {
 		write_enable(nor);
 		write_sr(nor, 0);
-- 
2.8.2