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

Message-ID: <CAK8P3a2TUAfhdoAL7u2fun7ZztrjGLxAGAX-WWDqsyNqP2=gZA@mail.gmail.com>
Date:   Mon, 6 Jul 2020 11:54:01 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Daniel Gutson <daniel@...ypsium.com>
Cc:     Derek Kiernan <derek.kiernan@...inx.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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 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 with a pair of exported functions:
  spi_lpc_register_info(struct spi_lpc_data *info);
  spi_lpc_unregister_info(struct spi_lpc_data *info);
  The names will have to change later, but the idea is that any driver
  can just pass the information you want to export to user space,
  and the interface module does not care where those values came
  from.

2. For any PCI device ID that is handled by drivers/mtd/spi-nor/intel-spi-pci.c,
  move the code to call the function from your driver into that file,
  reading the registers with pci_read_config_dword() or
  readl(ispi->base + CONSTANT).

3. For any PCI device ID that is handled by drivers/mfd/lpc_ich.c,
  do the same by moving the code to
  drivers/mtd/spi-nor/controllers/intel-spi-platform.c.

4. For any remaining PCI device ID you look at that does not have
  a driver, create a new PCI driver that binds to those IDs and
  does the same thing. If you have multiple device IDs that
  use the same register layout, then handle those with a common
  driver.

      Arnd