On Mon, Jan 24, 2022 at 11:25:17AM +1100, Daniel Axtens wrote:

Hi Greg,

quoted

Ok, this is like the 3rd or 4th different platform-specific proposal for
this type of functionality.  I think we need to give up on
platform-specific user/kernel apis on this (random sysfs/securityfs
files scattered around the tree), and come up with a standard place for
all of this.

I agree that we do have a number of platforms exposing superficially
similar functionality. Indeed, back in 2019 I had a crack at a unified
approach: [1] [2].

Looking back at it now, I am not sure it ever would have worked because
the semantics of the underlying firmware stores are quite
different. Here are the ones I know about:

 - OpenPower/PowerNV Secure Variables:
 
   * Firmware semantics:
     - flat variable space
     - variables are fixed in firmware, can neither be created nor
        destroyed
     - variable names are ASCII
     - no concept of policy/attributes
     
   * Current kernel interface semantics:
     - names are case sensitive
     - directory per variable     


 - (U)EFI variables:
 
   * Firmware semantics:
     - flat variable space
     - variables can be created/destroyed but the semantics are fiddly
        [3]
     - variable names are UTF-16 + UUID
     - variables have 32-bit attributes

   * efivarfs interface semantics:
     - file per variable
     - attributes are the first 4 bytes of the file
     - names are partially case-insensitive (UUID part) and partially
        case-sensitive ('name' part)

   * sysfs interface semantics (as used by CONFIG_GOOGLE_SMI)
     - directory per variable
     - attributes are a separate sysfs file
     - to create a variable you write a serialised structure to
        `/sys/firmware/efi/vars/new_var`, to delete a var you write
        to `.../del_var`
     - names are case-sensitive including the UUID


 - PowerVM Partition Key Store Variables:
 
   * Firmware semantics:
     - _not_ a flat space, there are 3 domains ("consumers"): firmware,
        bootloader and OS (not yet supported by the patch set)
     - variables can be created and destroyed but the semantics are
        fiddly and fiddly in different ways to UEFI [4]
     - variable names are arbitrary byte strings: the hypervisor permits
        names to contain nul and /.
     - variables have 32-bit attributes ("policy") that don't align with
        UEFI attributes

   * No stable kernel interface yet

Even if we could come up with some stable kernel interface features
(e.g. decide if we want file per variable vs directory per variable), I
don't know how easy it would be to deal with the underlying semantic
differences - I think userspace would still need substantial
per-platform knowledge.

Or have I misunderstood what you're asking for? (If you want them all to
live under /sys/firmware, these ones all already do...)

I want them to be unified in some way, right now there are lots of
proposals for the same type of thing, but in different places (sysfs,
securityfs, somewhere else), and with different names.

Please work together.

thanks,

greg k-h