Message-ID: <CAN8TOE8-9=P7p8Tkc+5kG5Sqan+RAWAc7k2VH-p5W9hR-bb_Xg@mail.gmail.com>
Date: Tue, 30 Jul 2024 10:28:48 -0700
From: Brian Norris <computersforpeace@...il.com>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: Michael Walle <mwalle@...nel.org>, linux-mtd@...ts.infradead.org, 
	Miquel Raynal <miquel.raynal@...tlin.com>, Pratyush Yadav <pratyush@...nel.org>, 
	Richard Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: micron-st: Add n25q064a WP support

Hi Tudor, Michael,

On Tue, Jul 30, 2024 at 4:33 AM Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
> On 7/30/24 7:51 AM, Michael Walle wrote:
> > On Fri Jul 26, 2024 at 8:58 PM CEST, Brian Norris wrote:
> >> These flash chips are used on Google / TP-Link / ASUS OnHub devices, and
> >> OnHub devices are write-protected by default (same as any other
> >> ChromeOS/Chromebook system). I've referred to datasheets, and tested on
> >> OnHub devices.
> >
> > Out of curiosity, there is also a hardware write protect switch
> > somehow, right? At least that's my understanding how verify boot
> > works.

There's a whole doc on this:
https://www.chromium.org/chromium-os/developer-library/reference/security/write-protection/

Short answer: yes.

If you want to see how this fits together in practice on a
non-ChromiumOS system, you can see my companion OpenWrt work here:
https://github.com/openwrt/openwrt/pull/16014

Basically, I just try to make it easier for tools (in this case, the
CrOS vboot tools) to find the write-protect GPIO, and cross-reference
that with the software (MTD "locked" ioctls) protection status. We
need to understand and manipulate both if we want to (temporarily)
remove write protection, while otherwise retaining verified boot
integrity.

> >> Signed-off-by: Brian Norris <computersforpeace@...il.com>
> >
> > This looks good:
> > Reviewed-by: Michael Walle <mwalle@...nel.org>
> >
> > But could you have a look whether this flash supports SFDP.
> > According to the datasheet it looks like it does. In that case,
> > could you please dump it according to:
> > https://docs.kernel.org/driver-api/mtd/spi-nor.html

Sorry, I didn't notice this doc. It's not technically a "new" flash,
so it doesn't necessarily apply, but for the mail-archive record:

# xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
53464450000100ff00000109300000ffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffe520f1ffffffff0329eb276b
083b27bbffffffffffff27bbffff29eb0c2010d800000000

> This would help getting rid of the no_sfdp_flags and size from the flash
> definition. Another reason is that the SFDP dump can help us
> differentiate between flavors of the same flash, if it'll ever be the
> case, and help us keep backward compatibility.

I wonder, since manufacturers seem to reuse IDs sometimes, is it
possible (or, likely) for SFDP and non-SFDP versions of the same flash
to exist? I'm not really sure whether I can truly drop the non-SFDP
definitions.

> Also, if you care, would be good to extend the SPI NOR documentation on
> how one shall test the Block Protection.

That sounds tougher. I don't know that there's really a standard
toolset for handling protection -- I guess the 'flash_{un,}lock'
utilities in mtd-utils qualify, but they aren't even packaged by
relevant distros (e.g., OpenWrt; but I guess they're in Debian). I
typically use flashrom, since that's what ChromiumOS uses, and it's
available in OpenWrt -- would that be an OK basis for docs?

It's also highly conditional on what sort of range(s) the flash
supports. So it's almost like we might want a programmatic
write-protection test suite as part of mtd-utils/tests/, rather than a
bespoke narrative document. Which ... is getting a little larger than
I signed up for.

Brian

Powered by blists - more mailing lists