From: David Laight <David.Laight@ACULAB.COM> To: 'Arnd Bergmann' <arnd@arndb.de>, Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Daniel Gutson <daniel@eclypsium.com>, Tudor Ambarus <tudor.ambarus@microchip.com>, Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Boris Brezillon <bbrezillon@kernel.org>, linux-mtd <linux-mtd@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Alex Bazhaniuk <alex@eclypsium.com>, "Richard Hughes" <hughsient@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Subject: RE: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable Date: Wed, 19 Aug 2020 09:19:52 +0000 [thread overview] Message-ID: <c62f0828d1f6463cb156107c0b21e219@AcuMS.aculab.com> (raw) In-Reply-To: <CAK8P3a0Bq-ucgC4Xue+B_HV97pTX8YRr4hYh1gfrfGBV_H1EUQ@mail.gmail.com> 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)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM> To: 'Arnd Bergmann' <arnd@arndb.de>, Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Richard Hughes <hughsient@gmail.com>, Vignesh Raghavendra <vigneshr@ti.com>, Boris Brezillon <bbrezillon@kernel.org>, Richard Weinberger <richard@nod.at>, Tudor Ambarus <tudor.ambarus@microchip.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-mtd <linux-mtd@lists.infradead.org>, Daniel Gutson <daniel@eclypsium.com>, Miquel Raynal <miquel.raynal@bootlin.com>, Alex Bazhaniuk <alex@eclypsium.com> Subject: RE: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable Date: Wed, 19 Aug 2020 09:19:52 +0000 [thread overview] Message-ID: <c62f0828d1f6463cb156107c0b21e219@AcuMS.aculab.com> (raw) In-Reply-To: <CAK8P3a0Bq-ucgC4Xue+B_HV97pTX8YRr4hYh1gfrfGBV_H1EUQ@mail.gmail.com> 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) ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-08-19 9:20 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-04 13:58 [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable Daniel Gutson 2020-08-04 13:58 ` Daniel Gutson 2020-08-04 14:08 ` Mika Westerberg 2020-08-04 14:08 ` Mika Westerberg 2020-08-04 15:21 ` Arnd Bergmann 2020-08-04 15:21 ` Arnd Bergmann [not found] ` <CAFmMkTHEm8k+5GZkVJbDZMEhMwpsqVKRb-hGskSpBstdLRuFyA@mail.gmail.com> 2020-08-04 19:06 ` Arnd Bergmann 2020-08-04 19:06 ` Arnd Bergmann 2020-08-04 19:57 ` Daniel Gutson 2020-08-04 19:57 ` Daniel Gutson 2020-08-04 20:46 ` Arnd Bergmann 2020-08-04 20:46 ` Arnd Bergmann 2020-08-04 21:26 ` Daniel Gutson 2020-08-04 21:26 ` Daniel Gutson 2020-08-12 15:41 ` Daniel Gutson 2020-08-12 15:41 ` Daniel Gutson 2020-08-13 9:01 ` Greg Kroah-Hartman 2020-08-13 9:01 ` Greg Kroah-Hartman [not found] ` <CAFmMkTFgjW+9gNfx=2SU7B0foww=SLiiyVi+P-hZpEFDbMTf2Q@mail.gmail.com> 2020-08-13 11:47 ` Greg Kroah-Hartman 2020-08-13 11:47 ` Greg Kroah-Hartman 2020-08-13 15:41 ` Arnd Bergmann 2020-08-13 15:41 ` Arnd Bergmann 2020-08-13 21:40 ` Daniel Gutson 2020-08-13 21:40 ` Daniel Gutson 2020-08-16 8:41 ` Arnd Bergmann 2020-08-16 8:41 ` Arnd Bergmann 2020-08-18 15:55 ` Daniel Gutson 2020-08-18 15:55 ` Daniel Gutson 2020-08-19 6:57 ` Mika Westerberg 2020-08-19 6:57 ` Mika Westerberg 2020-08-19 8:38 ` Arnd Bergmann 2020-08-19 8:38 ` Arnd Bergmann 2020-08-19 9:11 ` Mika Westerberg 2020-08-19 9:11 ` Mika Westerberg 2020-08-22 16:06 ` Arnd Bergmann 2020-08-22 16:06 ` Arnd Bergmann 2020-08-24 8:22 ` Mika Westerberg 2020-08-24 8:22 ` Mika Westerberg 2020-08-24 9:08 ` Arnd Bergmann 2020-08-24 9:08 ` Arnd Bergmann 2020-08-24 9:15 ` Mika Westerberg 2020-08-24 9:15 ` Mika Westerberg 2020-08-24 9:31 ` Arnd Bergmann 2020-08-24 9:31 ` Arnd Bergmann 2020-08-24 9:44 ` Mika Westerberg 2020-08-24 9:44 ` Mika Westerberg 2020-08-24 16:00 ` Daniel Gutson 2020-08-24 16:00 ` Daniel Gutson 2020-08-19 9:19 ` David Laight [this message] 2020-08-19 9:19 ` David Laight
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c62f0828d1f6463cb156107c0b21e219@AcuMS.aculab.com \ --to=david.laight@aculab.com \ --cc=alex@eclypsium.com \ --cc=arnd@arndb.de \ --cc=bbrezillon@kernel.org \ --cc=daniel@eclypsium.com \ --cc=gregkh@linuxfoundation.org \ --cc=hughsient@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=mika.westerberg@linux.intel.com \ --cc=miquel.raynal@bootlin.com \ --cc=richard@nod.at \ --cc=tudor.ambarus@microchip.com \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.