| Message ID | 20190520062553.14947-1-dja@axtens.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Generic Firmware Variable Filesystem | expand |
On 05/20/2019 02:25 AM, Daniel Axtens wrote: > Hi all, > > 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/ ? 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 ? Thanks & Regards, - Nayna
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. securityfs seems to be reserved for LSMs, I don't think we can put things there. 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. > 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. 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. Regards, Daniel
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
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
On 06/03/2019 07:56 PM, Daniel Axtens wrote: > >> 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. It seems efivars were first implemented in sysfs and then later separated out as efivarfs. Refer - Documentation/filesystems/efivarfs.txt. So, the reason wasn't that sysfs should not be used for exposing firmware variables, but for the size limitations which seems to come from UEFI Specification. Is this limitation valid for the new requirement of secure variables ? Copying Matthew who can give us more insights... Thanks & Regards, - Nayna
On Tue, Jun 4, 2019 at 1:01 PM Nayna <nayna@linux.vnet.ibm.com> wrote: > It seems efivars were first implemented in sysfs and then later > separated out as efivarfs. > Refer - Documentation/filesystems/efivarfs.txt. > > So, the reason wasn't that sysfs should not be used for exposing > firmware variables, > but for the size limitations which seems to come from UEFI Specification. > > Is this limitation valid for the new requirement of secure variables ? I don't think the size restriction is an issue now, but there's a lot of complex semantics around variable deletion and immutability that need to be represented somehow.
On 06/03/2019 03:29 AM, Greg KH wrote: > 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. Thanks Greg for clarifying!! I am curious, the TPM exposes the BIOS event log to userspace via securityfs. Is there a reason for not exposing these security variables to userspace via securityfs as well? Thanks & Regards, - Nayna
On Tue, Jun 04, 2019 at 04:33:14PM -0400, Nayna wrote: > > > On 06/03/2019 03:29 AM, Greg KH wrote: > > 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. > > Thanks Greg for clarifying!! I am curious, the TPM exposes the BIOS > event log to userspace via securityfs. Is there a reason for not > exposing these security variables to userspace via securityfs as well? securityfs is for LSMs to use. If the TPM drivers also use it, well, that's between those authors and the securityfs developers. BIOS/firmware variables are a much different thing than a TPM log. thanks, greg k-h
On Tue, Jun 04, 2019 at 01:05:45PM -0700, Matthew Garrett wrote: > On Tue, Jun 4, 2019 at 1:01 PM Nayna <nayna@linux.vnet.ibm.com> wrote: > > It seems efivars were first implemented in sysfs and then later > > separated out as efivarfs. > > Refer - Documentation/filesystems/efivarfs.txt. > > > > So, the reason wasn't that sysfs should not be used for exposing > > firmware variables, > > but for the size limitations which seems to come from UEFI Specification. > > > > Is this limitation valid for the new requirement of secure variables ? > > I don't think the size restriction is an issue now, but there's a lot > of complex semantics around variable deletion and immutability that > need to be represented somehow. Ah, yeah, that's the reason it would not work in sysfs, forgot all about that, thanks. greg k-h