linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Gutson <daniel.gutson@eclypsium.com>
Cc: Derek Kiernan <derek.kiernan@xilinx.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	linux-kernel@vger.kernel.org,
	Richard Hughes <hughsient@gmail.com>,
	Alex Bazhaniuk <alex@eclypsium.com>
Subject: Re: [PATCH] SPI LPC information kernel module
Date: Tue, 30 Jun 2020 10:56:41 +0200	[thread overview]
Message-ID: <20200630085641.GD637809@kroah.com> (raw)
In-Reply-To: <20200629225932.5036-1-daniel.gutson@eclypsium.com>

On Mon, Jun 29, 2020 at 07:59:32PM -0300, Daniel Gutson wrote:
> This kernel module exports configuration attributes for the
> system SPI chip.
> This initial version exports the BIOS Write Enable (bioswe),
> BIOS Lock Enable (ble), and the SMM Bios Write Protect (SMM_BWP)
> fields of the Bios Control register. The idea is to keep adding more
> flags, not only from the BC but also from other registers in following
> versions.
> 
> The goal is that the attributes are avilable to fwupd when SecureBoot
> is turned on.
> 
> A technical note: I check if *ppos == BUFFER_SIZE in the reading function
> to exit early and avoid an extra access to the HW, for example when using
> the 'cat' command, which causes two read operations.

Why not use the simple_* functions which should prevent that type of
thing?



> 
> Signed-off-by: Daniel Gutson <daniel.gutson@eclypsium.com>
> ---
>  Documentation/ABI/stable/securityfs-spi-lpc |  23 +

Why is this going in securityfs at all?  Why not just sysfs as it is a
CPU attribute, right?


>  MAINTAINERS                                 |   6 +
>  drivers/misc/Kconfig                        |   1 +
>  drivers/misc/Makefile                       |   1 +
>  drivers/misc/spi_lpc/Kconfig                |  20 +
>  drivers/misc/spi_lpc/Makefile               |   8 +
>  drivers/misc/spi_lpc/bios_data_access.c     | 559 +++++++++++++++++++
>  drivers/misc/spi_lpc/bios_data_access.h     | 181 +++++++
>  drivers/misc/spi_lpc/low_level_access.c     |  59 ++
>  drivers/misc/spi_lpc/low_level_access.h     |  21 +
>  drivers/misc/spi_lpc/spi_lpc_main.c         | 176 ++++++
>  drivers/misc/spi_lpc/viddid_arch_map.c      | 566 ++++++++++++++++++++
>  drivers/misc/spi_lpc/viddid_arch_map.h      |  17 +
>  13 files changed, 1638 insertions(+)
>  create mode 100644 Documentation/ABI/stable/securityfs-spi-lpc
>  create mode 100644 drivers/misc/spi_lpc/Kconfig
>  create mode 100644 drivers/misc/spi_lpc/Makefile
>  create mode 100644 drivers/misc/spi_lpc/bios_data_access.c
>  create mode 100644 drivers/misc/spi_lpc/bios_data_access.h
>  create mode 100644 drivers/misc/spi_lpc/low_level_access.c
>  create mode 100644 drivers/misc/spi_lpc/low_level_access.h
>  create mode 100644 drivers/misc/spi_lpc/spi_lpc_main.c
>  create mode 100644 drivers/misc/spi_lpc/viddid_arch_map.c
>  create mode 100644 drivers/misc/spi_lpc/viddid_arch_map.h
> 
> diff --git a/Documentation/ABI/stable/securityfs-spi-lpc b/Documentation/ABI/stable/securityfs-spi-lpc
> new file mode 100644
> index 000000000000..22660a7fd914
> --- /dev/null
> +++ b/Documentation/ABI/stable/securityfs-spi-lpc
> @@ -0,0 +1,23 @@
> +What:		/sys/kernel/security/firmware/bioswe
> +Date:		June 2020
> +KernelVersion:	5.8.0
> +Contact:	daniel.gutson@eclypsium.com
> +Description:	If the system firmware set BIOS Write Enable.
> +		0: writes disabled, 1: writes enabled.

THis is very x86-specific, what about ARM/MIPS/anything else?  Perhaps a
cpu/arch-specific thing instead?

Again, which makes it seem like securityfs is not the thing for this, as
it describes the hardware, not a security model which is what securityfs
has been for in the past, right?

thanks,

greg k-h

  parent reply	other threads:[~2020-06-30  8:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29 22:59 [PATCH] SPI LPC information kernel module Daniel Gutson
2020-06-30  8:02 ` kernel test robot
2020-06-30  8:56 ` Greg Kroah-Hartman [this message]
2020-06-30 13:57   ` Richard Hughes
2020-06-30 14:24     ` Arnd Bergmann
2020-06-30 15:14     ` Greg Kroah-Hartman
     [not found]   ` <CAFmMkTGrnZt7ZaGyYCe-LCHET4yHz9DfanaZwsOS6HCxK40apQ@mail.gmail.com>
2020-06-30 15:00     ` Arnd Bergmann
2020-06-30 15:28     ` Greg Kroah-Hartman
2020-06-30 15:32       ` Greg Kroah-Hartman
     [not found]       ` <CAFmMkTGy7u8oNSPmBHf9+URzKeNOxy5TJtqF3FCruRkTgJ_wGQ@mail.gmail.com>
2020-06-30 16:55         ` Greg Kroah-Hartman
2020-06-30  8:58 ` Arnd Bergmann
     [not found]   ` <CAFmMkTHrQ4LZk4+-3kdJ+dc47MXR1Jd76AXbO-ceT2zsfDRFGQ@mail.gmail.com>
2020-06-30 20:57     ` Arnd Bergmann
     [not found]       ` <CAFmMkTE3z6OZQ_v3jx-4MzMr8v+4qcF2uLn0ASGydj5oqDnfjg@mail.gmail.com>
2020-07-06  9:20         ` Arnd Bergmann
2020-07-06  9:54           ` Arnd Bergmann
     [not found]             ` <CAFmMkTGkmBgmv6wmS1kNWxGm0ktN56u9pJVJQKyPvLipyHsgqw@mail.gmail.com>
2020-07-14  6:38               ` Greg Kroah-Hartman
2020-07-06 10:22         ` Arnd Bergmann
2020-06-30  8:58 ` Greg Kroah-Hartman
2020-06-30  8:59 ` Greg Kroah-Hartman
2020-06-30  9:00 ` Greg Kroah-Hartman
2020-07-01  7:35 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200630085641.GD637809@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alex@eclypsium.com \
    --cc=arnd@arndb.de \
    --cc=daniel.gutson@eclypsium.com \
    --cc=derek.kiernan@xilinx.com \
    --cc=hughsient@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).