[PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable
arnd at arndb.de
Sun Aug 16 04:41:52 EDT 2020
On Thu, Aug 13, 2020 at 11:40 PM Daniel Gutson <daniel at eclypsium.com> wrote:
> On Thu, Aug 13, 2020 at 12:41 PM Arnd Bergmann <arnd at arndb.de> wrote:
> > On Tue, Aug 4, 2020 at 11:26 PM Daniel Gutson <daniel at eclypsium.com> wrote:
> > > On Tue, Aug 4, 2020 at 5:46 PM Arnd Bergmann <arnd at arndb.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
> then intel_spi_pci_probe will be called, where it unconditionally will
> try to make the chip writable
> 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
> 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:
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?
More information about the linux-mtd