Hi Greg,
> 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...)
Kind regards,
Daniel
[1]: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-May/190735.html
[2]: discussion continues at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-June/191365.html
[3]: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-June/191496.html
[4]: An unsigned variable cannot be updated, it can only be deleted
(unless it was created with the immutable policy) and then
re-created. A signed variable, on the other hand, can be updated
and the only way to delete it is to submit a validly signed empty
update.
