linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Daniel Gutson <daniel@eclypsium.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	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:57:21 +0300	[thread overview]
Message-ID: <20200819065721.GA1375436@lahna.fi.intel.com> (raw)
In-Reply-To: <CAFmMkTHqQO1Gj7VeXr4Y_Umb1KzZc2Pf=1pDQvPPpb_XeAFPqQ@mail.gmail.com>

On Tue, Aug 18, 2020 at 12:55:59PM -0300, Daniel Gutson wrote:
> > If you care about other (malicious) code writing to the driver, please explain
> > what the specific attack scenario is that you are worried about, and
> > why you think
> > this is not sufficient. What code would be able to write to the device
> > if not the
> > device driver itself?
> 
> Maybe Mika can answer this better, but what I'm trying to do is to
> limit the possibility of
> damage, as explained in the Kconfig:
> "Intel PCH/PCU SPI flash PCI driver (DANGEROUS)"
> "Say N here unless you know what you are doing. Overwriting the
>   SPI flash may render the system unbootable."

Right, the PCI part of the driver unconditionally (and wrongly) tried to
set the chip writeable.

What this whole thing tries to protect is that the user does not
accidentally write to the flash chip. It contains BIOS and other
important firmware so touching it (if it is not locked in the BIOS side)
may potentially brick the system. That's why we also require that
command line parameter so the user who knows what he or she is doing can
enable it for writing.

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.

  reply	other threads:[~2020-08-19  6:58 UTC|newest]

Thread overview: 25+ 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 14:08 ` Mika Westerberg
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:57       ` Daniel Gutson
2020-08-04 20:46         ` Arnd Bergmann
2020-08-04 21:26           ` Daniel Gutson
2020-08-12 15:41             ` Daniel Gutson
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 15:41             ` Arnd Bergmann
2020-08-13 21:40               ` Daniel Gutson
2020-08-16  8:41                 ` Arnd Bergmann
2020-08-18 15:55                   ` Daniel Gutson
2020-08-19  6:57                     ` Mika Westerberg [this message]
2020-08-19  8:38                       ` Arnd Bergmann
2020-08-19  9:11                         ` Mika Westerberg
2020-08-22 16:06                           ` Arnd Bergmann
2020-08-24  8:22                             ` Mika Westerberg
2020-08-24  9:08                               ` Arnd Bergmann
2020-08-24  9:15                                 ` Mika Westerberg
2020-08-24  9:31                                   ` Arnd Bergmann
2020-08-24  9:44                                     ` Mika Westerberg
2020-08-24 16:00                                       ` Daniel Gutson
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=20200819065721.GA1375436@lahna.fi.intel.com \
    --to=mika.westerberg@linux.intel.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).