Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200724212853.11601-1-daniel.gutson@eclypsium.com>
 <20200725055649.GA1047853@kroah.com> <CAFmMkTE_dT9+WJYyb19uQ_HmgJWZSARBy6PveheQJk++NuGbkQ@mail.gmail.com>
 <20200726071723.GB441916@kroah.com> <CAFmMkTFzGfFDrJrdgHztzLK2K-zBWy6T2Tv+G4-rrbVpbahkgg@mail.gmail.com>
 <CAK8P3a1nA7K15Cxz84Q8Grw3tKfgkUmsfURcytJEWb_0Wjqm5w@mail.gmail.com> <CAFmMkTExBY3V_Ghej7Bzjatg+vFtWq3UZmKzjAiEoR9EqnFN9Q@mail.gmail.com>
In-Reply-To: <CAFmMkTExBY3V_Ghej7Bzjatg+vFtWq3UZmKzjAiEoR9EqnFN9Q@mail.gmail.com>
From:   Daniel Gutson <daniel@eclypsium.com>
Date:   Wed, 29 Jul 2020 17:54:35 -0300
Message-ID: <CAFmMkTEO7VNKJeYz2uoHsS-yN_aY8UuiQ2GcCq9NyAD5481ZGA@mail.gmail.com>
Subject: Re: [PATCH] Module argument to control whether intel-spi-pci attempts
 to turn the SPI flash chip writeable
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Tudor Ambarus <tudor.ambarus@microchip.com>,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Boris Brezillon <bbrezillon@kernel.org>,
        linux-mtd <linux-mtd@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Alex Bazhaniuk <alex@eclypsium.com>,
        Richard Hughes <hughsient@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jul 27, 2020 at 12:31 PM Daniel Gutson <daniel@eclypsium.com> wrote=
:
>
> On Mon, Jul 27, 2020 at 12:15 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Mon, Jul 27, 2020 at 5:05 PM Daniel Gutson <daniel@eclypsium.com> wr=
ote:
> > > On Sun, Jul 26, 2020 at 4:17 AM Greg Kroah-Hartman <gregkh@linuxfound=
ation.org> wrote:
> > >>
> > >> On Sat, Jul 25, 2020 at 02:20:03PM -0300, Daniel Gutson wrote:
> > >> > El s=C3=A1b., 25 jul. 2020 2:56 a. m., Greg Kroah-Hartman <
> > >> > gregkh@linuxfoundation.org> escribi=C3=B3:
> > >> >
> > >> >
> > >> > 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 mechan=
ism 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.

ping.
This is a real existing problem that I'm trying to address.
There's currently no way to prevent the kernel to try to turn
the SPI flash chip writable for the device IDs handled by
intel-spi-pci. And allowing userspace to switch it between
writable/non-writable is not an option.
What other mechanism can I use other than the module parameter,
so
 - not accessible through user space
 - ideally set once, ideally at initialization time

Thanks,

    Daniel.


>
> >
> >      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


--=20
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