Currently, when setting efi variables through the runtime service,
efivarfs cannot sync variable updates properly. Introduce efivarfs
refresh remount to support efivarfs information updates from other
sources.

Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
---
 Documentation/filesystems/efivarfs.rst |  6 ++++
 fs/efivarfs/super.c                    | 40 +++++++++++++++++++++++++-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/Documentation/filesystems/efivarfs.rst b/Documentation/filesystems/efivarfs.rst
index f646c3f0980f..58461e02ad01 100644
--- a/Documentation/filesystems/efivarfs.rst
+++ b/Documentation/filesystems/efivarfs.rst
@@ -18,6 +18,12 @@ efivarfs is typically mounted like this::
 
 	mount -t efivarfs none /sys/firmware/efi/efivars
 
+To support efivar updates from other sources (efi_test ioctl, runtime
+driver, etc.), set ``efivarfs.refresh=1``. After that, remount will
+update the efivar information in efivarfs, like this::
+
+	mount -t efivarfs none /sys/firmware/efi/efivars -o remount
+
 Due to the presence of numerous firmware bugs where removing non-standard
 UEFI variables causes the system firmware to fail to POST, efivarfs
 files that are not well-known standardized variables are created
diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index beba15673be8..7ae22ca120e3 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -277,6 +277,44 @@ static const struct fs_parameter_spec efivarfs_parameters[] = {
 	{},
 };
 
+static bool efivarfs_refresh_default __read_mostly;
+module_param_named(refresh, efivarfs_refresh_default, bool, 0444);
+
+static void efivarfs_clean_dentry(struct dentry *dentry)
+{
+	struct dentry *child;
+
+	if (!dentry)
+		return;
+
+	if (d_is_dir(dentry)) {
+		spin_lock(&dentry->d_lock);
+		hlist_for_each_entry(child, &dentry->d_children, d_sib) {
+			if (child)
+				efivarfs_clean_dentry(child);
+		}
+		spin_unlock(&dentry->d_lock);
+	} else {
+		d_invalidate(dentry);
+	}
+}
+
+static int efivarfs_refresh(struct fs_context *fc)
+{
+	struct efivarfs_fs_info *sbi = fc->s_fs_info;
+
+	if (!efivarfs_refresh_default)
+		return 0;
+
+	if (!fc->root)
+		return -EINVAL;
+
+	efivarfs_clean_dentry(fc->root);
+	efivar_init(efivarfs_callback, fc->root->d_sb, &sbi->efivarfs_list);
+
+	return 0;
+}
+
 static int efivarfs_parse_param(struct fs_context *fc, struct fs_parameter *param)
 {
 	struct efivarfs_fs_info *sbi = fc->s_fs_info;
@@ -351,7 +389,7 @@ static int efivarfs_reconfigure(struct fs_context *fc)
 		return -EINVAL;
 	}
 
-	return 0;
+	return efivarfs_refresh(fc);
 }
 
 static const struct fs_context_operations efivarfs_context_ops = {
-- 
2.45.2

On Wed, 2025-01-15 at 22:14 +0800, Weizhao Ouyang wrote:
> Currently, when setting efi variables through the runtime service,
> efivarfs cannot sync variable updates properly. Introduce efivarfs
> refresh remount to support efivarfs information updates from other
> sources.

What other sources could there possibly be?  While the Linux kernel has
sole possession of the EFI RT interface after ExitBootServices has been
called, nothing else should be able to update the variables except
efivarfs.  This is a guarantee from UEFI so why do you think we can't
rely on it?

Regards,

James

On Wed, Jan 15, 2025 at 10:34 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Wed, 2025-01-15 at 22:14 +0800, Weizhao Ouyang wrote:
> > Currently, when setting efi variables through the runtime service,
> > efivarfs cannot sync variable updates properly. Introduce efivarfs
> > refresh remount to support efivarfs information updates from other
> > sources.
>
> What other sources could there possibly be?  While the Linux kernel has
> sole possession of the EFI RT interface after ExitBootServices has been
> called, nothing else should be able to update the variables except
> efivarfs.  This is a guarantee from UEFI so why do you think we can't
> rely on it?

One route that may exist is: drivers/firmware/efi/test/efi_test.c holds
some ioctls to call runtime service.

BR,
Weizhao

>
> Regards,
>
> James
>

On Wed, 2025-01-15 at 22:49 +0800, Weizhao Ouyang wrote:
> On Wed, Jan 15, 2025 at 10:34 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Wed, 2025-01-15 at 22:14 +0800, Weizhao Ouyang wrote:
> > > Currently, when setting efi variables through the runtime
> > > service, efivarfs cannot sync variable updates properly.
> > > Introduce efivarfs refresh remount to support efivarfs
> > > information updates from other sources.
> > 
> > What other sources could there possibly be?  While the Linux kernel
> > has sole possession of the EFI RT interface after ExitBootServices
> > has been called, nothing else should be able to update the
> > variables except efivarfs.  This is a guarantee from UEFI so why do
> > you think we can't rely on it?
> 
> One route that may exist is: drivers/firmware/efi/test/efi_test.c
> holds some ioctls to call runtime service.

That's not supposed to be used for anything other than direct testing
using the firmware test suite, which shouldn't impact production use of
efivarfs because it's defined to be N in Kconfig.   However, if we
suddenly decided there was a use case for production systems running
the test suite, the way forwards would be a notifier that tells
efivarfs about successful updates to variables as they occur without
having to remount.

Regards,

James

On Wed, 15 Jan 2025 at 15:58, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Wed, 2025-01-15 at 22:49 +0800, Weizhao Ouyang wrote:
> > On Wed, Jan 15, 2025 at 10:34 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > >
> > > On Wed, 2025-01-15 at 22:14 +0800, Weizhao Ouyang wrote:
> > > > Currently, when setting efi variables through the runtime
> > > > service, efivarfs cannot sync variable updates properly.
> > > > Introduce efivarfs refresh remount to support efivarfs
> > > > information updates from other sources.
> > >
> > > What other sources could there possibly be?  While the Linux kernel
> > > has sole possession of the EFI RT interface after ExitBootServices
> > > has been called, nothing else should be able to update the
> > > variables except efivarfs.  This is a guarantee from UEFI so why do
> > > you think we can't rely on it?
> >
> > One route that may exist is: drivers/firmware/efi/test/efi_test.c
> > holds some ioctls to call runtime service.
>
> That's not supposed to be used for anything other than direct testing
> using the firmware test suite, which shouldn't impact production use of
> efivarfs because it's defined to be N in Kconfig.   However, if we
> suddenly decided there was a use case for production systems running
> the test suite, the way forwards would be a notifier that tells
> efivarfs about successful updates to variables as they occur without
> having to remount.
>

I'd argue that running efi_test while efivarfs is mounted renders your
test results useless, and so there is no need to make them play nicely
together.

On Wed, Jan 15, 2025 at 11:00 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 15 Jan 2025 at 15:58, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > On Wed, 2025-01-15 at 22:49 +0800, Weizhao Ouyang wrote:
> > > On Wed, Jan 15, 2025 at 10:34 PM James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > >
> > > > On Wed, 2025-01-15 at 22:14 +0800, Weizhao Ouyang wrote:
> > > > > Currently, when setting efi variables through the runtime
> > > > > service, efivarfs cannot sync variable updates properly.
> > > > > Introduce efivarfs refresh remount to support efivarfs
> > > > > information updates from other sources.
> > > >
> > > > What other sources could there possibly be?  While the Linux kernel
> > > > has sole possession of the EFI RT interface after ExitBootServices
> > > > has been called, nothing else should be able to update the
> > > > variables except efivarfs.  This is a guarantee from UEFI so why do
> > > > you think we can't rely on it?
> > >
> > > One route that may exist is: drivers/firmware/efi/test/efi_test.c
> > > holds some ioctls to call runtime service.
> >
> > That's not supposed to be used for anything other than direct testing
> > using the firmware test suite, which shouldn't impact production use of
> > efivarfs because it's defined to be N in Kconfig.   However, if we
> > suddenly decided there was a use case for production systems running
> > the test suite, the way forwards would be a notifier that tells
> > efivarfs about successful updates to variables as they occur without
> > having to remount.
> >
>
> I'd argue that running efi_test while efivarfs is mounted renders your
> test results useless, and so there is no need to make them play nicely
> together.

Emm, yeah, so far this leans more towards a hacking scenario than a
production scenario.

BR,
Weizhao