From: Greg KH <email@example.com>
To: Nayna <firstname.lastname@example.org>
Cc: Daniel Axtens <email@example.com>,
George Wilson <firstname.lastname@example.org>,
Mimi Zohar <email@example.com>,
Matthew Garrett <firstname.lastname@example.org>,
Elaine Palmer <email@example.com>
Subject: Re: [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem
Date: Wed, 5 Jun 2019 08:14:17 +0200 [thread overview]
Message-ID: <20190605061417.GA29846@kroah.com> (raw)
On Tue, Jun 04, 2019 at 04:33:14PM -0400, Nayna wrote:
> On 06/03/2019 03:29 AM, Greg KH wrote:
> > On Mon, Jun 03, 2019 at 04:04:32PM +1000, Daniel Axtens wrote:
> > > Hi Nayna,
> > >
> > > > > As PowerNV moves towards secure boot, we need a place to put secure
> > > > > variables. One option that has been canvassed is to make our secure
> > > > > variables look like EFI variables. This is an early sketch of another
> > > > > approach where we create a generic firmware variable file system,
> > > > > fwvarfs, and an OPAL Secure Variable backend for it.
> > > > Is there a need of new filesystem ? I am wondering why can't these be
> > > > exposed via sysfs / securityfs ?
> > > > Probably, something like... /sys/firmware/secureboot or
> > > > /sys/kernel/security/secureboot/ ?
> > > I suppose we could put secure variables in sysfs, but I'm not sure
> > > that's what sysfs was intended for. I understand sysfs as "a
> > > filesystem-based view of kernel objects" (from
> > > Documentation/filesystems/configfs/configfs.txt), and I don't think a
> > > secure variable is really a kernel object in the same way most other
> > > things in sysfs are... but I'm open to being convinced.
> > What makes them more "secure" than anything else that is in sysfs today?
> > I didn't see anything in this patchset that provided "additional
> > security", did I miss it?
> > > securityfs seems to be reserved for LSMs, I don't think we can put
> > > things there.
> > Yeah, I wouldn't mess with that.
> Thanks Greg for clarifying!! I am curious, the TPM exposes the BIOS
> event log to userspace via securityfs. Is there a reason for not
> exposing these security variables to userspace via securityfs as well?
securityfs is for LSMs to use. If the TPM drivers also use it, well,
that's between those authors and the securityfs developers.
BIOS/firmware variables are a much different thing than a TPM log.
prev parent reply other threads:[~2019-06-05 6:14 UTC|newest]
Thread overview: 16+ 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 23:56 ` Daniel Axtens
2019-06-04 20:01 ` Nayna
2019-06-04 20:05 ` Matthew Garrett
2019-06-05 8:13 ` Greg KH
2019-06-04 20:33 ` Nayna
2019-06-05 6:14 ` Greg KH [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).