From: Nayna <nayna@linux.vnet.ibm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nayna Jain <nayna@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
linux-efi@vger.kernel.org,
linux-security-module <linux-security-module@vger.kernel.org>,
linux-kernel@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
npiggin@gmail.com, christophe.leroy@csgroup.eu,
Dov Murik <dovmurik@linux.ibm.com>,
George Wilson <gcwilson@linux.ibm.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Dave Hansen <dave.hansen@intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Russell Currey <ruscur@russell.cc>,
Andrew Donnellan <ajd@linux.ibm.com>,
Stefan Berger <stefanb@linux.ibm.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Subject: Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs
Date: Wed, 23 Nov 2022 13:57:58 -0500 [thread overview]
Message-ID: <6f2a4a5f-ab5b-8c1b-47d5-d4e6dca5fc3a@linux.vnet.ibm.com> (raw)
In-Reply-To: <Y35C9O27J29bUDjA@kroah.com>
On 11/23/22 10:57, Greg Kroah-Hartman wrote:
> On Wed, Nov 23, 2022 at 10:05:49AM -0500, Nayna wrote:
>> On 11/22/22 18:21, Nayna wrote:
>>> From the perspective of our use case, we need to expose firmware
>>> security objects to userspace for management. Not all of the objects
>>> pre-exist and we would like to allow root to create them from userspace.
>>>
>>> From a unification perspective, I have considered a common location at
>>> /sys/firmware/security for managing any platform's security objects. And
>>> I've proposed a generic filesystem, which could be used by any platform
>>> to represent firmware security objects via /sys/firmware/security.
>>>
>>> Here are some alternatives to generic filesystem in discussion:
>>>
>>> 1. Start with a platform-specific filesystem. If more platforms would
>>> like to use the approach, it can be made generic. We would still have a
>>> common location of /sys/firmware/security and new code would live in
>>> arch. This is my preference and would be the best fit for our use case.
>>>
>>> 2. Use securityfs. This would mean modifying it to satisfy other use
>>> cases, including supporting userspace file creation. I don't know if the
>>> securityfs maintainer would find that acceptable. I would also still
>>> want some way to expose variables at /sys/firmware/security.
>>>
>>> 3. Use a sysfs-based approach. This would be a platform-specific
>>> implementation. However, sysfs has a similar issue to securityfs for
>>> file creation. When I tried it in RFC v1[1], I had to implement a
>>> workaround to achieve that.
>>>
>>> [1] https://lore.kernel.org/linuxppc-dev/20220122005637.28199-3-nayna@linux.ibm.com/
>>>
>> Hi Greg,
>>
>> Based on the discussions so far, is Option 1, described above, an acceptable
>> next step?
> No, as I said almost a year ago, I do not want to see platform-only
> filesystems going and implementing stuff that should be shared by all
> platforms.
Given there are no other exploiters for fwsecurityfs and there should be
no platform-specific fs, would modifying sysfs now to let userspace
create files cleanly be the way forward? Or, if we should strongly
consider securityfs, which would result in updating securityfs to allow
userspace creation of files and then expose variables via a more
platform-specific directory /sys/kernel/security/pks? We want to pick
the best available option and would find some hints on direction helpful
before we develop the next patch.
Thanks & Regards,
- Nayna
next prev parent reply other threads:[~2022-11-23 18:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-06 21:07 [PATCH 0/4] powerpc/pseries: expose firmware security variables via filesystem Nayna Jain
2022-11-06 21:07 ` [PATCH 1/4] powerpc/pseries: Add new functions to PLPKS driver Nayna Jain
2022-11-06 21:07 ` [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs Nayna Jain
2022-11-07 9:35 ` kernel test robot
2022-11-09 13:46 ` Greg Kroah-Hartman
2022-11-09 20:10 ` Nayna
2022-11-10 9:58 ` Greg Kroah-Hartman
2022-11-14 23:03 ` Nayna
2022-11-17 21:27 ` Greg Kroah-Hartman
2022-11-19 6:20 ` Nayna
2022-11-20 16:13 ` Greg Kroah-Hartman
2022-11-21 3:14 ` James Bottomley
2022-11-21 11:05 ` Greg Kroah-Hartman
2022-11-21 14:03 ` James Bottomley
2022-11-21 15:05 ` Greg Kroah-Hartman
2022-11-21 17:33 ` James Bottomley
2022-11-21 18:12 ` Greg Kroah-Hartman
2022-11-21 16:12 ` David Laight
2022-11-21 19:34 ` Nayna
2022-11-19 11:48 ` Ritesh Harjani (IBM)
2022-11-22 23:21 ` Nayna
2022-11-23 15:05 ` Nayna
2022-11-23 15:57 ` Greg Kroah-Hartman
2022-11-23 18:57 ` Nayna [this message]
2022-12-12 0:58 ` Andrew Donnellan
2022-12-12 6:11 ` Greg Kroah-Hartman
2022-11-06 21:07 ` [PATCH 3/4] powerpc/pseries: initialize fwsecurityfs with plpks arch-specific structure Nayna Jain
2022-11-07 3:52 ` kernel test robot
2022-11-06 21:07 ` [PATCH 4/4] powerpc/pseries: expose authenticated variables stored in LPAR PKS Nayna Jain
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=6f2a4a5f-ab5b-8c1b-47d5-d4e6dca5fc3a@linux.vnet.ibm.com \
--to=nayna@linux.vnet.ibm.com \
--cc=ajd@linux.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@intel.com \
--cc=dovmurik@linux.ibm.com \
--cc=gcwilson@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mjg59@srcf.ucam.org \
--cc=mpe@ellerman.id.au \
--cc=nayna@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=ritesh.list@gmail.com \
--cc=ruscur@russell.cc \
--cc=serge@hallyn.com \
--cc=stefanb@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 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).