Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs
From: Nayna <hidden>
Date: 2022-11-23 18:58:51
Also in:
linux-efi, linux-fsdevel, linuxppc-dev, lkml
On 11/23/22 10:57, Greg Kroah-Hartman wrote:
On Wed, Nov 23, 2022 at 10:05:49AM -0500, Nayna wrote:quoted
On 11/22/22 18:21, Nayna wrote:quoted
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/ (local)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