From: Daniel Axtens <dja@axtens•net>
To: Greg KH <gregkh@linuxfoundation•org>, Nayna Jain <nayna@linux•ibm.com>
Cc: mjg59@srcf•ucam.org, linux-kernel@vger•kernel.org,
Douglas Miller <dougmill@linux•vnet.ibm.com>,
George Wilson <gcwilson@linux•ibm.com>,
linuxppc-dev@lists•ozlabs.org, gjoyce@ibm•com
Subject: Re: [RFC PATCH 0/2] powerpc/pseries: add support for local secure storage called Platform Keystore(PKS)
Date: Mon, 24 Jan 2022 11:25:17 +1100 [thread overview]
Message-ID: <87sftec74i.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <YeuyUVVdFADCuDr4@kroah.com>
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.
next prev parent reply other threads:[~2022-01-24 0:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-22 0:56 [RFC PATCH 0/2] powerpc/pseries: add support for local secure storage called Platform Keystore(PKS) Nayna Jain
2022-01-22 0:56 ` [RFC PATCH 1/2] pseries: define driver for Platform Keystore Nayna Jain
2022-01-22 0:56 ` [RFC PATCH 2/2] pseries: define sysfs interface to expose PKS variables Nayna Jain
2022-02-09 9:13 ` Dov Murik
2022-01-22 7:29 ` [RFC PATCH 0/2] powerpc/pseries: add support for local secure storage called Platform Keystore(PKS) Greg KH
2022-01-24 0:25 ` Daniel Axtens [this message]
2022-02-01 13:49 ` Greg KH
2022-02-01 15:22 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sftec74i.fsf@dja-thinkpad.axtens.net \
--to=dja@axtens$(echo .)net \
--cc=dougmill@linux$(echo .)vnet.ibm.com \
--cc=gcwilson@linux$(echo .)ibm.com \
--cc=gjoyce@ibm$(echo .)com \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mjg59@srcf$(echo .)ucam.org \
--cc=nayna@linux$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox