linux-kernel - Re: [PATCH] Module argument to control whether intel-spi-pci attempts to turn the SPI flash chip writeable

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]

Date:   Mon, 27 Jul 2020 12:31:27 -0300
From:   Daniel Gutson <daniel@...ypsium.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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>
Subject: Re: [PATCH] Module argument to control whether intel-spi-pci attempts
 to turn the SPI flash chip writeable

On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson <daniel@...ypsium.com> wrote:
> > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> >>
> >> On Sat, Jul 25, 2020 at 02:20:03PM -0300, Daniel Gutson wrote:
> >> > El sáb., 25 jul. 2020 2:56 a. m., Greg Kroah-Hartman <
> >> > gregkh@...uxfoundation.org> escribió:
> >> >
> >> >
> >> > 1) I just did the same that intel-spi.c does.
> >>
> >> No need to copy bad examples :)
> >
> >
> > Didn't know it was a bad example. What's is the current modern mechanism that replaces initialization-time configuration?
>
> I'd say you'd generally want this to be a per-instance setting, which
> could be a sysfs attribute of the physical device, or an ioctl for an
> existing user space abstraction.

But still, they are not equivalent. The initial configuration remains
constant for the rest of the life of the driver, whereas the
sysfs attribute is set after the initialization and can be re-set over
time. I'm not asking module parameters "to come back" if
they are now considered obsolete, I'm just trying to understand.

>
> In the changelog, you should also explain what this is used for. Do
> you actually want to write to a device that is marked read-only, or
> are you just trying to make the interface more consistent between the
> two drivers?

The device can either be locked or unlocked. If it is unlocked, it can
be set writable depending on the module
argument in intel-spi, or straight writable in intel-spi-pci. Which is
dangerous.
I wanted to make, as you say, the interface consistent.
Exposing an interface to the user (via a sysfs attribute) to try to
make the driver writable is definitively a bad idea.
I'd rather do nothing (no module arg) rather than open that
here-be-dragons door.
>
>      Arnd



-- 
Daniel Gutson
Argentina Site Director
Enginieering Director
Eclypsium

Below The Surface: Get the latest threat research and insights on
firmware and supply chain threats from the research team at Eclypsium.
https://eclypsium.com/research/#threatreport