Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction

[Ard Biesheuvel]

On Fri, 25 Sep 2020 at 02:51, joeyli <jlee@xxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx>
> > > Cc: Matthias Brugger <mbrugger@xxxxxxxx>
> > > Cc: Fabian Vogt <fvogt@xxxxxxxx>
> > > Cc: Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx>
> > > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > Cc: Arthur Heymans <arthur@xxxxxxxxxxxx>
> > > Cc: Patrick Rudolph <patrick.rudolph@xxxxxxxxxxxxx>
> > > Signed-off-by: "Lee, Chun-Yi" <jlee@xxxxxxxx>
> > > ---
> >
> > 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.