Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200924082833.12722-1-jlee@suse.com> <CAMj1kXE64kMU7wnMQK+k=0tjaH9OMOrzN86yJPPRkx5Nq8XBqw@mail.gmail.com>
 <20200925005049.GD31226@linux-l9pv.suse>
In-Reply-To: <20200925005049.GD31226@linux-l9pv.suse>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 25 Sep 2020 09:01:36 +0200
Message-ID: <CAMj1kXFtg854N4PjrV_8ZKdibYKGoEHH5NV_kjTOTt7EKPANaQ@mail.gmail.com>
Subject: Re: [PATCH] efi/efivars: Create efivars mount point in the
 registration of efivars abstraction
To:     joeyli <jlee@suse.com>
Cc:     "Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        linux-efi <linux-efi@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Matthias Brugger <mbrugger@suse.com>,
        Fabian Vogt <fvogt@suse.com>,
        Ilias Apalodimas <ilias.apalodimas@linaro.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Arthur Heymans <arthur@aheymans.xyz>,
        Patrick Rudolph <patrick.rudolph@9elements.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 25 Sep 2020 at 02:51, joeyli <jlee@suse.com> wrote:
>
> Hi Ard,
>
> On Thu, Sep 24, 2020 at 12:47:46PM +0200, Ard Biesheuvel wrote:
> > On Thu, 24 Sep 2020 at 10:28, Lee, Chun-Yi <joeyli.kernel@gmail.com> wrote:
> > >
> > > This patch moved the logic of creating efivars mount point to the
> > > registration of efivars abstraction. It's useful for userland to
> > > determine the availability of efivars filesystem by checking the
> > > existence of mount point.
> > >
> > > The 'efivars' platform device be created on generic EFI runtime services
> > > platform, so it can be used to determine the availability of efivarfs.
> > > But this approach is not available for google gsmi efivars abstraction.
> > >
> > > This patch be tested on Here on qemu-OVMF and qemu-uboot.
> > >
> > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > Cc: Matthias Brugger <mbrugger@suse.com>
> > > Cc: Fabian Vogt <fvogt@suse.com>
> > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Arthur Heymans <arthur@aheymans.xyz>
> > > Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
> > > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> > > ---
> >
> > I take it this is v3 of [0]? If so, please explain how it deviates
> > from v2. If it doesn't deviate from v2, it is better to continue the
> > discussion in the other thread.
> >
> > For the sake of discussion, it helps to clarify the confusing nomenclature:
> >
> > a) 'efivars abstraction' - an internal kernel API that exposes EFI
> > variables, and can potentially be backed by an implementation that is
> > not EFI based (i.e., Google gsmi)
> >
> > b) efivars.ko module, built on top of the efivars abstraction, which
> > exposes EFI variables (real ones or gsmi ones) via the deprecated
> > sysfs interface
> >
> > c) efivarfs filesystem, also built on top of the efivars abstraction,
> > which exposes EFI variables (real ones or gsmi ones) via a special
> > filesystem independently of sysfs.
> >
> > Of course, the sysfs mount point we create for efivarfs is not called
> > 'efivarfs' but 'efivars'. The sysfs subdirectory we create for
> > efivars.ko is called 'vars'. Sigh.
> >
>
> Thanks for your clarification. It's useful to me!
>
> >
> > In this patch, you create the mount point for c) based on whether a)
> > gets registered (which occurs on systems with EFI Get/SetVariable
> > support or GSMI), right? So, to Greg's point, wouldn't it be easier to
> > simply check whether efivarfs is listed in /proc/filesystems?
> >
>
> Yes, I think that Greg's suggestion is good enough for a userland tool
> to detect the availability of efivarfs. You can ignore my patch.
>

Excellent! Thanks for confirming.