Hi Greg, >> >> 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? You're right, there's no additional security. What I should have said was that I didn't think that _firmware_ variables were kernel objects in the same way that other things in sysfs are. Having read the rest of your reply it seems I'm mistaken on this. > I would just recommend putting this in sysfs. Make a new subsystem > (i.e. class) and away you go. > >> My hope with fwvarfs is to provide a generic place for firmware >> variables so that we don't need to expand the list of firmware-specific >> filesystems beyond efivarfs. I am also aiming to make things simple to >> use so that people familiar with firmware don't also have to become >> familiar with filesystem code in order to expose firmware variables to >> userspace. >> fwvarfs can also be used for variables that are not security relevant as >> well. For example, with the EFI backend (patch 3), both secure and >> insecure variables can be read. > > I don't remember why efi variables were not put in sysfs, I think there > was some reasoning behind it originally. Perhaps look in the linux-efi > archives. I'll have a look: I suspect the appeal of efivarfs is that it allows for things like non-case-sensitive matching on the GUID part of the filename while retaining case-sensitivity on the part of the filename representing the variable name. As suggested, I'll try a sysfs class. I think that will allow me to kill off most of the abstraction layer too. Thanks for the input. Regards, Daniel > > thanks, > > greg k-h
