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: <CAN8TOE-YGSRxjrMNqHWfP7RYKUnPs-V=d_FFJfZtquPedEe+dA@mail.gmail.com>
Date: Wed, 31 Jul 2024 10:10:32 -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,

On Wed, Jul 31, 2024 at 1:51 AM Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
> A shasum on the SFDP dump would be good to have some sort of integrity
> assurance, e.g.:
> sha256sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp

# sha256sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
2030d04758164491e414e1d55e16b04803f5653fb591fda50991c728c49c1c37
/sys/bus/spi/devices/spi0.0/spi-nor/sfdp

> Some test in mtd-utils would be good indeed, but narrative shall be also
> ok for now. What I fear is that people just use just a flash lock/unlock
> all sectors test, which is not ideal. We shall also test locking on some
> sectors from the top and bottom, to verify the correctness of the TB
> bit, check if BP3 is working by locking some sectors in that area.
> Haven't looked at the BP area in a while, but you get my point, I feel
> testing is not ideal and a guideline would help.
>
> If you ever feel that you can spend some time on this, help is appreciated.

OK. It's possible, but no guarantees. I think in the distant past
(when I was still maintaining some of this area), I actually started
to write such a mtd-utils test, but I never cleaned it up and
submitted it. For one, a proper exhaustive test would be rather slow,
as we'd want to test all the possible protection ranges, and then
erase/write/read the whole thing. Some rough measurement on my system
shows about a minute for erasing the whole chip, 25 seconds for
writing, and 7 seconds for reading -- which means with 5 bits of
protection range (4 bits, plus top/bottom bit) we have 32 combinations
* ~1.5 minutes test = 48 minutes. That's ... doable I guess, and it
could probably be optimized a bit to reduce the number of erase
cycles. But it's not great.

Anyway, maybe I'll play with it.

Brian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ