[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c62f0828d1f6463cb156107c0b21e219@AcuMS.aculab.com>
Date: Wed, 19 Aug 2020 09:19:52 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Arnd Bergmann' <arnd@...db.de>,
Mika Westerberg <mika.westerberg@...ux.intel.com>
CC: Daniel Gutson <daniel@...ypsium.com>,
Tudor Ambarus <tudor.ambarus@...rochip.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Boris Brezillon <bbrezillon@...nel.org>,
linux-mtd <linux-mtd@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alex Bazhaniuk <alex@...ypsium.com>,
"Richard Hughes" <hughsient@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: RE: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash
chip writable
From: Arnd Bergmann
> Sent: 19 August 2020 09:38
...
> If you are really worried about the write protection being bypassed by
> a different driver or code injection, the best way would seem to be to
> only enable writing in the mtd write callback and disable it immediately
> after the write is complete. I still don't see why this hardware would
> be more susceptible to this kind of attack than other drivers though,
> as it already has the safeguard against writing through the MTD layer
> without the module parameter.
It is pretty unlikely that anyone will accidentally do an spi write
(it is all too complicated).
Anything that is being mischievous can send the write enable
command itself.
If you care you need to use the device pin to disable writes.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists