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

Arnd Bergmann arnd at arndb.de
Tue Aug 4 16:46:34 EDT 2020


On Tue, Aug 4, 2020 at 9:57 PM Daniel Gutson <daniel at eclypsium.com> wrote:
> On Tue, Aug 4, 2020 at 4:06 PM Arnd Bergmann <arnd at arndb.de> wrote:
> > On Tue, Aug 4, 2020 at 5:49 PM Daniel Gutson <daniel at eclypsium.com> wrote:
> > > On Tue, Aug 4, 2020 at 12:21 PM Arnd Bergmann <arnd at arndb.de> wrote:
> > >> On Tue, Aug 4, 2020 at 3:58 PM Daniel Gutson
> > >> <daniel.gutson at eclypsium.com> wrote:
> > >
> > > What about just saying
> > >
> > > "This patch removes the attempt by the intel-spi-pci driver to
> > > make the chip always writable."
> >
> > Yes, that is much better, though it still sounds like it would at the
> > moment allow writing to the device from software without also
> > setting the module parameter. I would say something like
> >
> > "Disallow overriding the write protection in the PCI driver
> > with a module parameter and instead honor the current
> > state of the write protection as set by the firmware."
>
> 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), but that only touches the hardware
write-protection, which doesn't really have any effect unless user
space also configures the driver module to allow writing to the
mtd device.

> So I'm not touching intel-pci, just removing that code from
> intel-spi-pci without adding a new module parameter.
>
> Are you aligned on this?

One of us is still very confused about what the driver does.
You seem to have gone back to saying that without the
change a user could just write to the device even without
passing the module parameter to intel-spi.ko?

Maybe you should start by explaining what scenario you
actually want to prevent here. Is it

a) the hardware write-protect bit getting changed, which
    introduces the possibility of corrupting the flash even
    if nothing tries to write to it,

b) root users setting the device writable with the intention
   of writing to it even though firmware has politely asked
   for this not to be done (by setting the write-protect bit
   but not preventing it from being disabled again), or

c) a writeable mtd device showing up even without
    the module parameter being set at all?

I thought the initial patch was about c) which turned out
to be a non-issue, and then the later patch being about b).

     Arnd



More information about the linux-mtd mailing list