linux-kernel - Re: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable

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: <CAK8P3a2_RV33kiJ0c34aopZ4iG7LYBR-u=-+BbC+Upyjh1T0Eg@mail.gmail.com>
Date:   Sun, 16 Aug 2020 10:41:52 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Daniel Gutson <daniel@...ypsium.com>
Cc:     Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Mika Westerberg <mika.westerberg@...ux.intel.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

On Thu, Aug 13, 2020 at 11:40 PM Daniel Gutson <daniel@...ypsium.com> wrote:
>
> On Thu, Aug 13, 2020 at 12:41 PM Arnd Bergmann <arnd@...db.de> wrote:
> >
> > On Tue, Aug 4, 2020 at 11:26 PM Daniel Gutson <daniel@...ypsium.com> wrote:
> > > On Tue, Aug 4, 2020 at 5:46 PM Arnd Bergmann <arnd@...db.de> wrote:
> > > > > But wait, Mika, the author of the file, asked earlier not to remove
> > > > > the module parameter of intel-spi, and just remove the unconditional
> > > > > attempt to turn the chip writable in intle-spi-pci.
> > > >
> > > > Yes, and I think that is fine (aside from the inconsistency with bay trail
> > > > that you have not commented on),
> > >
> > > There are two inconsistencies before any of my patches:
> > > 1) in intel-spi.c: uses the module parameter only for bay trail.
> > > 2) intel-spi.c uses a module parameter whereas intel-spi-pci doesn't
> >
> > Neither of these matches what I see in the source code. Please
> > check again.
> >
> > Once more: intel-spi.c has a module parameter that controls writing
> > to the device regardless of the back-end (platform or pci), purely
> > in software.
>
> If I understand you correctly, this is not what I see:
> If the deviceID is listed in intel-spi-pci.c
> (https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/controllers/intel-spi-pci.c#L66)
> then intel_spi_pci_probe will be called, where it unconditionally will
> try to make the chip writable
> https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/controllers/intel-spi-pci.c#L44
> These devices correspond to the BXT and CNL devices (lines 19 and 23 resp.).
>
> Lines later (53), it will call intel-spi.c 's intel_spi_probe
> function, which ends up calling intel_spi_init,
> which checks for the type
> (https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/controllers/intel-spi.c#L313)
> It is in this switch where the module parameter is checked, but only
> in the BYT case; however,
> flow coming from intel-spi-pci is BXT and CNL as mentioned before,
> landing in their case labels (lines 343 and 351 respectively)
> where the module parameter is not checked.
>
> Therefore, for BXT and CNL probed in intel-spi-pci, the chip is turned
> writable and later the module parameter is not honored.

The module parameter is definitely honored on all hardware, but the driver
only cares about the functionality it provides through the mtd interface:

https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/controllers/intel-spi.c#L941

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?

    Arnd