All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier@dowhile0.org>
To: Richard Hughes <hughsient@gmail.com>
Cc: platform-driver-x86@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] platform/x86: Export LPC attributes for the system SPI chip
Date: Thu, 7 May 2020 19:05:31 +0200	[thread overview]
Message-ID: <CABxcv=kTL_grDUL00c_e2jyPD4hTtFS8Jze6pQBEz_arR6TPVA@mail.gmail.com> (raw)
In-Reply-To: <18e48255d68a1408b3e3152780f0e789df540059.camel@gmail.com>

Hello Richard,

On Wed, May 6, 2020 at 5:52 PM Richard Hughes <hughsient@gmail.com> wrote:
>
> Export standard LPC configuration values from various LPC/eSPI
> controllers. This allows userspace components such as fwupd to
> verify the most basic SPI protections are set correctly.
> For instance, checking BIOSWE is disabled and BLE is enabled.
>
> More cutting-edge checks (e.g. PRx and BootGuard) can be added
> once the basics are in place. Exporting these values from the
> kernel allows us to report the security level of the platform
> without rebooting and running an unsigned EFI binary like
> chipsec.
>
> Signed-off-by: Richard Hughes <richard@hughsie.com>
> ---

The patch looks good to me, I just have some small comments.

> +config INTEL_SPI_LPC
> +       tristate "Intel SPI LPC configuration"
> +       depends on SECURITY

Maybe "depends on SECURITYFS" instead? I would also add ||
COMPILE_TEST to have more build coverage.

Another option is to not even add a dependency here since the
securityfs_*() functions are still defined if SECURITYFS isn't
enabled. They just return -ENODEV.

[snip]

> +       spi_dir = securityfs_create_dir("spi", NULL);
> +       if (IS_ERR(spi_dir))
> +               return -1;
> +
> +       spi_bioswe =
> +           securityfs_create_file("bioswe",
> +                                  0600, spi_dir, NULL,
> +                                  &spi_bioswe_ops);
> +       if (IS_ERR(spi_bioswe))
> +               goto out;
> +       spi_ble =
> +           securityfs_create_file("ble",
> +                                  0600, spi_dir, NULL,
> +                                  &spi_ble_ops);
> +       if (IS_ERR(spi_ble))
> +               goto out;
> +       spi_smm_bwp =
> +           securityfs_create_file("smm_bwp",
> +                                  0600, spi_dir, NULL,
> +                                  &spi_smm_bwp_ops);
> +       if (IS_ERR(spi_smm_bwp))
> +               goto out;
> +
> +       return 0;
> +out:
> +       securityfs_remove(spi_bioswe);
> +       securityfs_remove(spi_ble);
> +       securityfs_remove(spi_smm_bwp);

I don't think this is needed since if smm_bwp was successfully created
then it will never reach the error handling.

> +       securityfs_remove(spi_dir);

The convention is to remove these in the reverse order that were created, i.e:

securityfs_remove(spi_ble);
securityfs_remove(spi_bioswe);
securityfs_remove(spi_dir);

> +static void __exit mod_exit(void)
> +{
> +       securityfs_remove(spi_bioswe);
> +       securityfs_remove(spi_ble);
> +       securityfs_remove(spi_smm_bwp);
> +       securityfs_remove(spi_dir);
> +}
> +

Same here. It makes it easier if in the future other entries are added.

I wonder if these new entries should be documented in
Documentation/ABI/. Or maybe that's not a requirement for securityfs?

Best regards,
Javier

  parent reply	other threads:[~2020-05-07 17:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 15:52 [PATCH] platform/x86: Export LPC attributes for the system SPI chip Richard Hughes
2020-05-06 16:29 ` Andy Shevchenko
2020-05-06 16:39   ` Richard Hughes
2020-05-07 17:05 ` Javier Martinez Canillas [this message]
2020-05-07 17:22   ` Andy Shevchenko
2020-05-07 17:28     ` Javier Martinez Canillas
2020-05-07 17:45 ` Mario.Limonciello
2020-05-07 17:45   ` Mario.Limonciello
2020-05-07 18:47   ` Richard Hughes
2020-05-07 19:22     ` Mario.Limonciello
2020-05-07 19:22       ` Mario.Limonciello
2020-05-07 19:49       ` Richard Hughes
2020-05-07 20:03         ` Mario.Limonciello
2020-05-07 20:03           ` Mario.Limonciello
2020-05-08  8:20           ` Mika Westerberg
2020-05-08 16:15             ` Richard Hughes
2020-05-11 10:45               ` Mika Westerberg
2020-05-11 15:40                 ` Richard Hughes
2020-05-11 16:28                   ` Mika Westerberg
2020-05-11 20:08                     ` Richard Hughes
2020-05-12  6:44                       ` Mika Westerberg
2020-05-12 20:37                         ` Richard Hughes
2020-05-08 17:27             ` Mario.Limonciello
2020-05-08 17:27               ` Mario.Limonciello
2020-05-11 10:41               ` Mika Westerberg

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='CABxcv=kTL_grDUL00c_e2jyPD4hTtFS8Jze6pQBEz_arR6TPVA@mail.gmail.com' \
    --to=javier@dowhile0.org \
    --cc=hughsient@gmail.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=platform-driver-x86@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.