linux-kernel - Re: [PATCH v3 00/15] mtd: spi-nor: macronix: workaround for device id re-use

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: <D2NGXHZ2VTK0.M0AOB4CM7MHM@kernel.org>
Date: Fri, 12 Jul 2024 11:55:08 +0200
From: "Michael Walle" <mwalle@...nel.org>
To: "Esben Haabendal" <esben@...nix.com>, "Tudor Ambarus"
 <tudor.ambarus@...aro.org>, "Pratyush Yadav" <pratyush@...nel.org>, "Miquel
 Raynal" <miquel.raynal@...tlin.com>, "Richard Weinberger" <richard@....at>,
 "Vignesh Raghavendra" <vigneshr@...com>, "Nicolas Ferre"
 <nicolas.ferre@...rochip.com>, "Alexandre Belloni"
 <alexandre.belloni@...tlin.com>, "Claudiu Beznea"
 <claudiu.beznea@...on.dev>
Cc: <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>, "Rasmus
 Villemoes" <rasmus.villemoes@...vas.dk>,
 <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 00/15] mtd: spi-nor: macronix: workaround for device
 id re-use

Hi,

On Thu Jul 11, 2024 at 3:00 PM CEST, Esben Haabendal wrote:
> As a consequence, the SPI_NOR_SKIP_SFDP flag is no more, and all
> drivers that have been doing optional SFDP is now marked explicitly to
> do that using the SPI_NOR_TRY_SFDP.

First, I haven't looked at your patchset at the moment. But I'd like
to take the opportunity to discuss the following (and excuse me that
I didn't had this idea before all your work on this).

First, I'd like to see it the other way around, that is, doing SFDP
by default and let the driver opt-out instead of opt-in. This will
also align with the current "SFDP only driver", i.e. if a flash is
not known we try SFDP anyway. Going forward, I'd say this is also
the sane behavior and we don't have to add any flags if someone want
to add support for an (older) flash with the same ID but without
SFDP. With the current approach, we'd have to add the TRY_SFDP flag.

Now we might play it safe and add that SPI_NOR_SKIP_SFDP to any
flash which doesn't do the SFDP parsing (because it has size != 0
and not any of the magic flags set) - or we might just go ahead and
do the probing first for *any* flashes. Yes we might issue an
unsupported opcode, but we already do that with the generic SFDP
flash driver. So no big deal maybe (?). Vendors where we know for a
fact that they don't have any SFDP (Everspin I'm looking at you),
would of course set the SKIP_SFDP flag.

-michael

Download attachment "signature.asc" of type "application/pgp-signature" (298 bytes)