On Fri, Jan 09, 2026 at 02:17:52PM +0530, Srish Srinivasan wrote: > Hi Jarkko, > thank you for taking a look. > > On 1/8/26 6:57 PM, Jarkko Sakkinen wrote: > > On Tue, Jan 06, 2026 at 08:35:26PM +0530, Srish Srinivasan wrote: > > > The wrapping key does not exist by default and is generated by the > > > hypervisor as a part of PKWM initialization. This key is then persisted by > > > the hypervisor and is used to wrap trusted keys. These are variable length > > > symmetric keys, which in the case of PowerVM Key Wrapping Module (PKWM) > > > are > > > generated using the kernel RNG. PKWM can be used as a trust source through > > > the following example keyctl commands: > > > > > > keyctl add trusted my_trusted_key "new 32" @u > > > > > > Use the wrap_flags command option to set the secure boot requirement for > > > the wrapping request through the following keyctl commands > > > > > > case1: no secure boot requirement. (default) > > > keyctl usage: keyctl add trusted my_trusted_key "new 32" @u > > > OR > > > keyctl add trusted my_trusted_key "new 32 wrap_flags=0x00" @u > > > > > > case2: secure boot required to in either audit or enforce mode. set bit 0 > > > keyctl usage: keyctl add trusted my_trusted_key "new 32 wrap_flags=0x01" > > > @u > > > > > > case3: secure boot required to be in enforce mode. set bit 1 > > > keyctl usage: keyctl add trusted my_trusted_key "new 32 wrap_flags=0x02" > > > @u > > > > > > NOTE: > > > -> Setting the secure boot requirement is NOT a must. > > > -> Only either of the secure boot requirement options should be set. Not > > > both. > > > -> All the other bits are required to be not set. > > > -> Set the kernel parameter trusted.source=pkwm to choose PKWM as the > > > backend for trusted keys implementation. > > > -> CONFIG_PSERIES_PLPKS must be enabled to build PKWM. > > > > > > Add PKWM, which is a combination of IBM PowerVM and Power LPAR Platform > > > KeyStore, as a new trust source for trusted keys. > > > > > > Signed-off-by: Srish Srinivasan <[email protected]> > > > Reviewed-by: Mimi Zohar <[email protected]> > > > --- > > > MAINTAINERS | 9 ++ > > > include/keys/trusted-type.h | 7 +- > > > include/keys/trusted_pkwm.h | 22 +++ > > > security/keys/trusted-keys/Kconfig | 8 ++ > > > security/keys/trusted-keys/Makefile | 2 + > > > security/keys/trusted-keys/trusted_core.c | 6 +- > > > security/keys/trusted-keys/trusted_pkwm.c | 168 ++++++++++++++++++++++ > > > 7 files changed, 220 insertions(+), 2 deletions(-) > > > create mode 100644 include/keys/trusted_pkwm.h > > > create mode 100644 security/keys/trusted-keys/trusted_pkwm.c > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index a0dd762f5648..ba51eff21a16 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -14003,6 +14003,15 @@ S: Supported > > > F: include/keys/trusted_dcp.h > > > F: security/keys/trusted-keys/trusted_dcp.c > > > +KEYS-TRUSTED-PLPKS > > > +M: Srish Srinivasan <[email protected]> > > > +M: Nayna Jain <[email protected]> > > > +L: [email protected] > > > +L: [email protected] > > > +S: Supported > > > +F: include/keys/trusted_plpks.h > > > +F: security/keys/trusted-keys/trusted_pkwm.c > > > + > > > KEYS-TRUSTED-TEE > > > M: Sumit Garg <[email protected]> > > > L: [email protected] > > > diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h > > > index 4eb64548a74f..45c6c538df22 100644 > > > --- a/include/keys/trusted-type.h > > > +++ b/include/keys/trusted-type.h > > > @@ -19,7 +19,11 @@ > > > #define MIN_KEY_SIZE 32 > > > #define MAX_KEY_SIZE 128 > > > -#define MAX_BLOB_SIZE 512 > > > +#if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM) > > > +#define MAX_BLOB_SIZE 1152 > > > +#else > > > +#define MAX_BLOB_SIZE 512 > > > +#endif > > > #define MAX_PCRINFO_SIZE 64 > > > #define MAX_DIGEST_SIZE 64 > > > @@ -46,6 +50,7 @@ struct trusted_key_options { > > > uint32_t policydigest_len; > > > unsigned char policydigest[MAX_DIGEST_SIZE]; > > > uint32_t policyhandle; > > > + uint16_t wrap_flags; > > > }; > > We should introduce: > > > > void *private; > > > > And hold backend specific fields there. > > > > This patch set does not necessarily have to migrate TPM fields to this > > new framework, only start a better convention before this turns into > > a chaos. > > > Sure, > thanks for bringing this up. > I will make the required changes in my next version.
Great! TPM fields are where they are more like through history and evolution than by design. While not required, of course migrating also them is a most welcome additional patch :-) BR, Jarkko
