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
next prev 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).