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:

quoted

On Tue, Jan 06, 2026 at 08:35:26PM +0530, Srish Srinivasan wrote:

quoted

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 <ssrish@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
  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 <ssrish@linux.ibm.com>
+M:	Nayna Jain <nayna@linux.ibm.com>
+L:	linux-integrity@vger.kernel.org
+L:	keyrings@vger.kernel.org
+S:	Supported
+F:	include/keys/trusted_plpks.h
+F:	security/keys/trusted-keys/trusted_pkwm.c
+
  KEYS-TRUSTED-TEE
  M:	Sumit Garg <sumit.garg@kernel.org>
  L:	linux-integrity@vger.kernel.org

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