On Wed, Nov 09, 2022 at 03:10:37PM -0500, Nayna wrote:
On 11/9/22 08:46, Greg Kroah-Hartman wrote:Ok, then just use the normal sysfs interface for /sys/firmware, why do
On Sun, Nov 06, 2022 at 04:07:42PM -0500, Nayna Jain wrote:From man 5 sysfs page:
securityfs is meant for Linux security subsystems to expose policies/logsWhy not juset use securityfs in /sys/security/firmware/ instead? Then
or any other information. However, there are various firmware security
features which expose their variables for user management via the kernel.
There is currently no single place to expose these variables. Different
platforms use sysfs/platform specific filesystem(efivarfs)/securityfs
interface as they find it appropriate. Thus, there is a gap in kernel
interfaces to expose variables for security features.
Define a firmware security filesystem (fwsecurityfs) to be used by
security features enabled by the firmware. These variables are platform
specific. This filesystem provides platforms a way to implement their
own underlying semantics by defining own inode and file operations.
Similar to securityfs, the firmware security filesystem is recommended
to be exposed on a well known mount point /sys/firmware/security.
Platforms can define their own directory or file structure under this path.
Example:
# mount -t fwsecurityfs fwsecurityfs /sys/firmware/security
you don't have to create a new filesystem and convince userspace to
mount it in a specific location?
/sys/firmware: This subdirectory contains interfaces for viewing and
manipulating firmware-specific objects and attributes.
/sys/kernel: This subdirectory contains various files and subdirectories
that provide information about the running kernel.
The security variables which are being exposed via fwsecurityfs are managed
by firmware, stored in firmware managed space and also often consumed by
firmware for enabling various security features.
you need a whole new filesystem type?
From git commit b67dbf9d4c1987c370fd18fdc4cf9d8aaea604c2, the purpose ofsysfs is confusing already, no problem with making it more confusing :)
securityfs(/sys/kernel/security) is to provide a common place for all kernel
LSMs. The idea of
fwsecurityfs(/sys/firmware/security) is to similarly provide a common place
for all firmware security objects.
/sys/firmware already exists. The patch now defines a new /security
directory in it for firmware security features. Using /sys/kernel/security
would mean scattering firmware objects in multiple places and confusing the
purpose of /sys/kernel and /sys/firmware.
Just document where you add things and all should be fine.
Even though fwsecurityfs code is based on securityfs, since the twoWait, why would a user ever create a file in this filesystem? If you
filesystems expose different types of objects and have different
requirements, there are distinctions:
1. fwsecurityfs lets users create files in userspace, securityfs only allows
kernel subsystems to create files.
need that, why not use configfs? That's what that is for, right?
2. firmware and kernel objects may have different requirements. For example,I do not understand, sorry. What does namespaces have to do with this?
consideration of namespacing. As per my understanding, namespacing is
applied to kernel resources and not firmware resources. That's why it makes
sense to add support for namespacing in securityfs, but we concluded that
fwsecurityfs currently doesn't need it. Another but similar example of it
is: TPM space, which is exposed from hardware. For containers, the TPM would
be made as virtual/software TPM. Similarly for firmware space for
containers, it would have to be something virtualized/software version of
it.
sysfs can already handle namespaces just fine, why not use that?
3. firmware objects are persistent and read at boot time by interaction withThat doesn't matter, sysfs exports what the hardware provides, and that
firmware, unlike kernel objects which are not persistent.
might persist over boot.
So I don't see why a new filesystem is needed.
You didn't explain why sysfs, or securitfs (except for the location in
the tree) does not work at all for your needs. The location really
doesn't matter all that much as you are creating a brand new location
anyway so we can just declare "this is where this stuff goes" and be ok.
And again, how are you going to get all Linux distros to now mount your
new filesystem?
thanks,
greg k-h