Messages in this thread | | | Date | Wed, 23 Nov 2022 10:05:49 -0500 | Subject | Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs | From | Nayna <> |
| |
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?
Thanks & Regards,
- Nayna
| |