linux-kernel - Re: [PATCH] SPI LPC information kernel module

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>] [day] [month] [year] [list]

Message-ID: <20200714063820.GD662760@kroah.com>
Date:   Tue, 14 Jul 2020 08:38:20 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Daniel Gutson <daniel@...ypsium.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Derek Kiernan <derek.kiernan@...inx.com>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Richard Hughes <hughsient@...il.com>,
        Alex Bazhaniuk <alex@...ypsium.com>
Subject: Re: [PATCH] SPI LPC information kernel module

On Mon, Jul 13, 2020 at 07:24:11PM -0300, Daniel Gutson wrote:
> On Mon, Jul 6, 2020 at 6:54 AM Arnd Bergmann <arnd@...db.de> wrote:
> 
> > On Mon, Jul 6, 2020 at 11:20 AM Arnd Bergmann <arnd@...db.de> wrote:
> > >
> > > > Because of these reasons, I'm proposing a misc (not-device) driver
> > that supports
> > > > many Intel architectures (and families) to expose the information.
> > > > I understand your proposal to first enhance existing _device_ drivers,
> > but I
> > > > couldn't find suitable options.
> > >
> > > Maybe try adding an interface to one of the drivers at first, and then
> > extend
> > > it to the other hardware after an initial code review. Do not bypass the
> > driver
> > > model or try to do everything at once with a single module that knows
> > > details of multiple unrelated hardware implementations.
> >
> > To clarify further how I think you can have a chance of getting the
> > interface you want, here's a step-by-step list:
> >
> > 1. keep the current securityfs interface (or any other user space
> >   ABI if you have already changed it), but put it into a separate loadable
> >   module
> 
> 
> If it is a loadable module, how can I ensure that it was loaded before the
> intel-spi driver, so the latter can call
> the API of the former? What if the driver was not loaded, when the
> intel-spi driver will try to call
> your suggested spi_lpc_register_info? In other words, how can I prevent to
> call functions from an unloaded driver?

THe symbol will not be resolved so the module will not be able to be
loaded in the first place, OR your module will be loaded first by the
system to prevent that.

> Do I just add the dependency in the Kconfig? But if so, what about the
> order of initialization?
> A hint please?

Try it and see what happens, it should all "just work" :)

thanks,

greg k-h