On Mon, Jun 03, 2019 at 04:04:32PM +1000, Daniel Axtens wrote: > Hi Nayna, > > >> 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? > securityfs seems to be reserved for LSMs, I don't think we can put > things there. Yeah, I wouldn't mess with that. 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. Why would anyone need to be writing new code to firmware variables that makes it any different from any other kernel change? > > Also, it sounds like this is needed only for secure firmware variables > > and does not include > > other firmware variables which are not security relevant ? Is that > > correct understanding ? > > The primary use case at the moment - OPAL secure variables - is security > focused because the current OPAL secure variable design stores and > manipulates secure variables separately from the rest of nvram. This > isn't an inherent feature of fwvarfs. Again, why not just put it in sysfs please? > 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. thanks, greg k-h
