linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan+linaro@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	Jeremy Kerr <jk@ozlabs.org>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Johan Hovold <johan+linaro@kernel.org>
Subject: [PATCH 0/4] efi: verify that variable services are supported
Date: Thu, 19 Jan 2023 17:42:51 +0100	[thread overview]
Message-ID: <20230119164255.28091-1-johan+linaro@kernel.org> (raw)

This series adds a sanity check to make sure that the variable services
are actually available before registering the generic efivar ops.

This is used to address some potential races with custom efivars
implementation such as the Google SMI or upcoming Qualcomm SCM ones.

Specifically, efivarfs currently requires that the efivar ops have been
registered before module init time even though the Google driver can be
built as a module. Instead, the driver has so far relied on the fact
that the generic ops have been registered by efi core only to later be
overridden by the custom implementation (or Google doesn't use
efivarfs).

Instead, let's move the efivars sanity check to mount time to allow for
late registration of efivars.

Note that requiring that all efivars implementation to always be
built-in and registered before module init time could be an alternative,
but we'd still need to make sure that the custom implementation is then
not overridden by the default (broken) one. To avoid such init call
games, allowing late registration seems preferable.

This would however require any drivers that use efivars to probe defer
until it becomes available, which is also unfortunate, but possibly
still better than having generic kernels carry multiple built-in efivars
implementations.

Note that there are currently no such (efivars consumer) drivers in-tree
except for the efivars_pstore driver, which currently do rely on
efivarfs being available at module init time (and hence may fail to
initialise with the custom efivar implementations).

Johan


Johan Hovold (4):
  efi: efivars: add efivars printk prefix
  efivarfs: always register filesystem
  efi: verify that variable services are supported
  efi: efivars: prevent double registration

 drivers/firmware/efi/efi.c  | 22 ++++++++++++++++++++++
 drivers/firmware/efi/vars.c | 17 ++++++++++++++---
 fs/efivarfs/super.c         |  6 +++---
 3 files changed, 39 insertions(+), 6 deletions(-)

-- 
2.38.2


             reply	other threads:[~2023-01-19 16:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 16:42 Johan Hovold [this message]
2023-01-19 16:42 ` [PATCH 1/4] efi: efivars: add efivars printk prefix Johan Hovold
2023-01-19 16:42 ` [PATCH 2/4] efivarfs: always register filesystem Johan Hovold
2023-01-20  9:23   ` Ard Biesheuvel
2023-01-20 16:04     ` Johan Hovold
2023-01-23 11:32       ` Ard Biesheuvel
2023-01-19 16:42 ` [PATCH 3/4] efi: verify that variable services are supported Johan Hovold
2023-01-19 16:42 ` [PATCH 4/4] efi: efivars: prevent double registration Johan Hovold
2023-01-23 12:06 ` [PATCH 0/4] efi: verify that variable services are supported Ard Biesheuvel

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=20230119164255.28091-1-johan+linaro@kernel.org \
    --to=johan+linaro@kernel.org \
    --cc=ardb@kernel.org \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=mjg59@srcf.ucam.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).