On Sat, Aug 22, 2020 at 06:06:03PM +0200, Arnd Bergmann wrote: > On Wed, Aug 19, 2020 at 11:11 AM Mika Westerberg > <[email protected]> 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 > > > <[email protected]> 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.
OK, thanks. Since we cannot really get rid of the module parameter (AFAIK there are users for it), I still think we should just make the "writeable" to apply to the PCI part as well. That should at least make it consistent, and it also solves Daniel's case.
