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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMj1kXFtg854N4PjrV_8ZKdibYKGoEHH5NV_kjTOTt7EKPANaQ@mail.gmail.com>
Date:   Fri, 25 Sep 2020 09:01:36 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     joeyli <jlee@...e.com>
Cc:     "Lee, Chun-Yi" <joeyli.kernel@...il.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthias Brugger <mbrugger@...e.com>,
        Fabian Vogt <fvogt@...e.com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arthur Heymans <arthur@...ymans.xyz>,
        Patrick Rudolph <patrick.rudolph@...ements.com>
Subject: Re: [PATCH] efi/efivars: Create efivars mount point in the
 registration of efivars abstraction

On Fri, 25 Sep 2020 at 02:51, joeyli <jlee@...e.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@...il.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@...nel.org>
> > > Cc: Matthias Brugger <mbrugger@...e.com>
> > > Cc: Fabian Vogt <fvogt@...e.com>
> > > Cc: Ilias Apalodimas <ilias.apalodimas@...aro.org>
> > > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > Cc: Arthur Heymans <arthur@...ymans.xyz>
> > > Cc: Patrick Rudolph <patrick.rudolph@...ements.com>
> > > Signed-off-by: "Lee, Chun-Yi" <jlee@...e.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.