From: Arnd Bergmann <arnd@arndb.de>
To: 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: Sat, 22 Aug 2020 18:06:03 +0200 [thread overview]
Message-ID: <CAK8P3a19MLfQARXEWzCD-ySq4t9nsyryB+con33HsQ193+muMw@mail.gmail.com> (raw)
In-Reply-To: <20200819091123.GE1375436@lahna.fi.intel.com>
On Wed, Aug 19, 2020 at 11:11 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> On Wed, Aug 19, 2020 at 10:38:24AM +0200, Arnd Bergmann wrote:
> > On Wed, Aug 19, 2020 at 8:57 AM Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
>
> > > Actually thinking about this bit more, to make PCI and the platform
> > > parts consistent we can make the "writeable" control this for the PCI
> > > part as well. So what if we add a callback to struct intel_spi_boardinfo
> > > that the PCI driver populates and then the "core" driver uses to enable
> > > writing when "writeable" is set to 1.
> >
> > 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.
>
> Hmm, is there already a mechanism at the MTD level to prevent writes? If
> that's the case then sure we can use that instead.
The mtd core just checks both the permissions on the device node (which
default to 0600 without any special udev rules) and the MTD_WRITEABLE
on the underlying device that is controlled by the module parameter
in case of intel-spi{,-platform,-pci}.c.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: 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: Sat, 22 Aug 2020 18:06:03 +0200 [thread overview]
Message-ID: <CAK8P3a19MLfQARXEWzCD-ySq4t9nsyryB+con33HsQ193+muMw@mail.gmail.com> (raw)
In-Reply-To: <20200819091123.GE1375436@lahna.fi.intel.com>
On Wed, Aug 19, 2020 at 11:11 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> On Wed, Aug 19, 2020 at 10:38:24AM +0200, Arnd Bergmann wrote:
> > On Wed, Aug 19, 2020 at 8:57 AM Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
>
> > > Actually thinking about this bit more, to make PCI and the platform
> > > parts consistent we can make the "writeable" control this for the PCI
> > > part as well. So what if we add a callback to struct intel_spi_boardinfo
> > > that the PCI driver populates and then the "core" driver uses to enable
> > > writing when "writeable" is set to 1.
> >
> > 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.
>
> Hmm, is there already a mechanism at the MTD level to prevent writes? If
> that's the case then sure we can use that instead.
The mtd core just checks both the permissions on the device node (which
default to 0600 without any special udev rules) and the MTD_WRITEABLE
on the underlying device that is controlled by the module parameter
in case of intel-spi{,-platform,-pci}.c.
Arnd
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-08-22 16:06 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 [this message]
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
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=CAK8P3a19MLfQARXEWzCD-ySq4t9nsyryB+con33HsQ193+muMw@mail.gmail.com \
--to=arnd@arndb.de \
--cc=alex@eclypsium.com \
--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: link
Be 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.