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@xxxxxxxxxxxxx/ > > > 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. thanks, greg k-h
