From: Greg KH <gregkh@linuxfoundation.org>
To: Matthew Garrett <mjg59@google.com>
Cc: Nayna <nayna@linux.vnet.ibm.com>,
Nayna Jain <nayna@linux.ibm.com>,
Claudio Carvalho <cclaudio@linux.ibm.com>,
Mimi Zohar <zohar@linux.ibm.com>,
George Wilson <gcwilson@us.ibm.com>,
Elaine Palmer <erpalmer@us.ibm.com>,
linux-fsdevel@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Daniel Axtens <dja@axtens.net>
Subject: Re: [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem
Date: Wed, 5 Jun 2019 10:13:01 +0200 [thread overview]
Message-ID: <20190605081301.GA23180@kroah.com> (raw)
In-Reply-To: <CACdnJutpgxd0Se-UDR4Gw3s+KfTuHprUTqFqxq+qu17vd4xr7Q@mail.gmail.com>
On Tue, Jun 04, 2019 at 01:05:45PM -0700, Matthew Garrett wrote:
> On Tue, Jun 4, 2019 at 1:01 PM Nayna <nayna@linux.vnet.ibm.com> wrote:
> > It seems efivars were first implemented in sysfs and then later
> > separated out as efivarfs.
> > Refer - Documentation/filesystems/efivarfs.txt.
> >
> > So, the reason wasn't that sysfs should not be used for exposing
> > firmware variables,
> > but for the size limitations which seems to come from UEFI Specification.
> >
> > Is this limitation valid for the new requirement of secure variables ?
>
> I don't think the size restriction is an issue now, but there's a lot
> of complex semantics around variable deletion and immutability that
> need to be represented somehow.
Ah, yeah, that's the reason it would not work in sysfs, forgot all about
that, thanks.
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Matthew Garrett <mjg59@google.com>
Cc: Nayna <nayna@linux.vnet.ibm.com>, Daniel Axtens <dja@axtens.net>,
linux-fsdevel@vger.kernel.org, Nayna Jain <nayna@linux.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Claudio Carvalho <cclaudio@linux.ibm.com>,
George Wilson <gcwilson@us.ibm.com>,
Mimi Zohar <zohar@linux.ibm.com>,
Elaine Palmer <erpalmer@us.ibm.com>
Subject: Re: [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem
Date: Wed, 5 Jun 2019 10:13:01 +0200 [thread overview]
Message-ID: <20190605081301.GA23180@kroah.com> (raw)
In-Reply-To: <CACdnJutpgxd0Se-UDR4Gw3s+KfTuHprUTqFqxq+qu17vd4xr7Q@mail.gmail.com>
On Tue, Jun 04, 2019 at 01:05:45PM -0700, Matthew Garrett wrote:
> On Tue, Jun 4, 2019 at 1:01 PM Nayna <nayna@linux.vnet.ibm.com> wrote:
> > It seems efivars were first implemented in sysfs and then later
> > separated out as efivarfs.
> > Refer - Documentation/filesystems/efivarfs.txt.
> >
> > So, the reason wasn't that sysfs should not be used for exposing
> > firmware variables,
> > but for the size limitations which seems to come from UEFI Specification.
> >
> > Is this limitation valid for the new requirement of secure variables ?
>
> I don't think the size restriction is an issue now, but there's a lot
> of complex semantics around variable deletion and immutability that
> need to be represented somehow.
Ah, yeah, that's the reason it would not work in sysfs, forgot all about
that, thanks.
greg k-h
next prev parent reply other threads:[~2019-06-05 8:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 6:25 [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem Daniel Axtens
2019-05-20 6:25 ` [WIP RFC PATCH 1/6] kernfs: add create() and unlink() hooks Daniel Axtens
2019-05-20 6:25 ` [WIP RFC PATCH 2/6] fwvarfs: a generic firmware variable filesystem Daniel Axtens
2019-05-20 6:25 ` [WIP RFC PATCH 3/6] fwvarfs: efi backend Daniel Axtens
2019-05-20 6:25 ` [WIP RFC PATCH 4/6] powerpc/powernv: Add support for OPAL secure variables Daniel Axtens
2019-05-20 6:25 ` [WIP RFC PATCH 5/6] powerpc/powernv: Remove EFI " Daniel Axtens
2019-05-20 6:25 ` [WIP RFC PATCH 6/6] fwvarfs: Add opal_secvar backend Daniel Axtens
2019-05-31 4:04 ` [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem Nayna
2019-06-03 6:04 ` Daniel Axtens
2019-06-03 7:29 ` Greg KH
2019-06-03 7:29 ` Greg KH
2019-06-03 23:56 ` Daniel Axtens
2019-06-03 23:56 ` Daniel Axtens
2019-06-04 20:01 ` Nayna
2019-06-04 20:01 ` Nayna
2019-06-04 20:05 ` Matthew Garrett
2019-06-04 20:05 ` Matthew Garrett
2019-06-05 8:13 ` Greg KH [this message]
2019-06-05 8:13 ` Greg KH
2019-06-04 20:33 ` Nayna
2019-06-04 20:33 ` Nayna
2019-06-05 6:14 ` Greg KH
2019-06-05 6:14 ` Greg KH
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=20190605081301.GA23180@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=cclaudio@linux.ibm.com \
--cc=dja@axtens.net \
--cc=erpalmer@us.ibm.com \
--cc=gcwilson@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mjg59@google.com \
--cc=nayna@linux.ibm.com \
--cc=nayna@linux.vnet.ibm.com \
--cc=zohar@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.