* Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking
From: David Howells @ 2026-02-02 9:21 UTC (permalink / raw)
To: Eric Biggers
Cc: dhowells, =?UTF-8?q?Mihai-Drosi=20C=C3=A2ju?=, linux, arnd,
arnout, atomlin, bigeasy, chleroy, christian, corbet, coxu,
da.gomez, da.gomez, dmitry.kasatkin, eric.snowberg,
f.gruenbichler, jmorris, kpcyrd, linux-arch, linux-doc,
linux-integrity, linux-kbuild, linux-kernel, linux-modules,
linux-security-module, linuxppc-dev, lkp, maddy, mattia, mcgrof,
mpe, nathan, naveen, nicolas.bouchinet, nicolas.schier, npiggin,
nsc, paul, petr.pavlu, roberto.sassu, samitolvanen, serge,
xiujianfeng, zohar
In-Reply-To: <20260201201218.GA15755@quark>
Eric Biggers <ebiggers@kernel.org> wrote:
> With that being the case, why is there still effort being put into
> adding more features to module signing? I would think efforts should be
> focused on hash-based module authentication, i.e. this patchset.
Because it's not just signing of modules and it's not just modules built with
the kernel. Also a hash table just of module hashes built into the core
kernel image will increase the size of the kernel by around a third of a meg
(on Fedora 43 and assuming SHA512) with uncompressible data.
David
^ permalink raw reply
* Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()
From: Paul Moore @ 2026-02-02 4:07 UTC (permalink / raw)
To: Tetsuo Handa
Cc: SELinux, linux-security-module, Steffen Klassert, Herbert Xu,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Network Development
In-Reply-To: <93d291db-4175-48c4-830c-e83bab373ae2@I-love.SAKURA.ne.jp>
On Sat, Jan 31, 2026 at 1:01 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2026/01/31 6:56, Paul Moore wrote:
> > On Wed, Jan 28, 2026 at 5:28 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >> On 2026/01/28 6:59, Paul Moore wrote:
> >>> It sounds like we either need to confirm that
> >>> security_xfrm_{policy,state}_delete() is already present in all code
> >>> paths that result in SPD/SAD deletions (in a place that can safely
> >>> fail and return an error),
> >>
> >> Yes.
> >
> > To clarify, do you mean "yes, I agree", or "yes, I've already checked
> > this and can confirm that the LSM hooks are already being called"?
>
> I mean "yes, I agree".
>
> >
> >>> or we need to place
> >>> xfrm_dev_{policy,state}_flush_secctx_check() in a location that can
> >>> safely fail.
> >>
> >> Did you mean xfrm_{policy,state}_flush_secctx_check() ?
> >
> > They both call into the security_xfrm_policy_delete() LSM hook which
> > is what I care about as that hook is what authorizes the operation.
>
> I can't understand what your authorization is.
I'm asking you to verify that we have the LSM xfrm hooks in all of the
necessary locations to ensure that we are safely and comprehensively
gating all of the operations that result in removal of SPD and SAD
entries.
> No authorization can be placed during must-not-fail operation.
Of course, but that means that we simply need to make sure we have the
authorization hooks placed elsewhere to ensure that users can not
remove SPD and SAD entries if they are not allowed. I'm not arguing
about if returning an error in a place that can not handle an error
condition is correct or not, I'm arguing that you should audit the SPD
and SAD removal code paths to ensure that they all have the proper LSM
xfrm hook authorizations.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 5/6] selftests/landlock: Repurpose scoped_abstract_unix_test.c for pathname sockets too.
From: Tingmao Wang @ 2026-02-02 0:06 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Justin Suess, linux-security-module
In-Reply-To: <20260129.ePhaehieJoh4@digikod.net>
On 1/29/26 21:28, Mickaël Salaün wrote:
> [...]
> On Tue, Dec 30, 2025 at 05:20:23PM +0000, Tingmao Wang wrote:
>> [...]
>> @@ -308,6 +413,12 @@ TEST_F(scoped_audit, connect_to_child)
>> char buf;
>> int dgram_client;
>> struct audit_records records;
>> + struct service_fixture *const dgram_address =
>> + variant->abstract_socket ? &self->dgram_address_abstract :
>> + &self->dgram_address_pathname;
>> + size_t log_match_remaining = 500;
>
> const
>
> Why this number? Could you please follow the same logic as in
> matches_log_fs_extra()?
It's not a const since we decrement it below as we fill log_match with
stpncpy().
matches_log_fs_extra() uses 2*PATH_MAX + length of various fixed strings.
I guess since the path is a resolved absolute path which can vary based on
where this test is ran, it is safest to use a value based on PATH_MAX. I
will update.
>
>> + char log_match[log_match_remaining];
>> + char *log_match_cursor = log_match;
>>
>> /* Makes sure there is no superfluous logged records. */
>> EXPECT_EQ(0, audit_count_records(self->audit_fd, &records));
>> @@ -330,8 +441,8 @@ TEST_F(scoped_audit, connect_to_child)
>>
>> dgram_server = socket(AF_UNIX, SOCK_DGRAM, 0);
>> ASSERT_LE(0, dgram_server);
>> - ASSERT_EQ(0, bind(dgram_server, &self->dgram_address.unix_addr,
>> - self->dgram_address.unix_addr_len));
>> + ASSERT_EQ(0, bind(dgram_server, &dgram_address->unix_addr,
>> + dgram_address->unix_addr_len));
>>
>> /* Signals to the parent that child is listening. */
>> ASSERT_EQ(1, write(pipe_child[1], ".", 1));
>> @@ -345,7 +456,9 @@ TEST_F(scoped_audit, connect_to_child)
>> EXPECT_EQ(0, close(pipe_child[1]));
>> EXPECT_EQ(0, close(pipe_parent[0]));
>>
>> - create_scoped_domain(_metadata, LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET);
>> + create_scoped_domain(_metadata,
>> + LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET |
>> + LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET);
>>
>> /* Signals that the parent is in a domain, if any. */
>> ASSERT_EQ(1, write(pipe_parent[1], ".", 1));
>> @@ -355,19 +468,62 @@ TEST_F(scoped_audit, connect_to_child)
>>
>> /* Waits for the child to listen */
>> ASSERT_EQ(1, read(pipe_child[0], &buf, 1));
>> - err_dgram = connect(dgram_client, &self->dgram_address.unix_addr,
>> - self->dgram_address.unix_addr_len);
>> + err_dgram = connect(dgram_client, &dgram_address->unix_addr,
>> + dgram_address->unix_addr_len);
>> EXPECT_EQ(-1, err_dgram);
>> EXPECT_EQ(EPERM, errno);
>>
>> - EXPECT_EQ(
>> - 0,
>> - audit_match_record(
>> - self->audit_fd, AUDIT_LANDLOCK_ACCESS,
>> + if (variant->abstract_socket) {
>> + log_match_cursor = stpncpy(
>> + log_match,
>> REGEX_LANDLOCK_PREFIX
>> " blockers=scope\\.abstract_unix_socket path=" ABSTRACT_SOCKET_PATH_PREFIX
>> "[0-9A-F]\\+$",
>> - NULL));
>> + log_match_remaining);
>> + log_match_remaining =
>> + sizeof(log_match) - (log_match_cursor - log_match);
>> + ASSERT_NE(0, log_match_remaining);
>> + } else {
>> + /*
>> + * It is assumed that absolute_path does not contain control
>> + * characters nor spaces, see audit_string_contains_control().
>> + */
>> + char *absolute_path =
>
> const char *absolute_path
Can't use const char * here since we free() it later:
scoped_unix_test.c:513:22: warning: passing argument 1 of ‘free’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
513 | free(absolute_path);
| ^~~~~~~~~~~~~
But I guess we can char *const. Will update to:
char *const absolute_path =
realpath(dgram_address->unix_addr.sun_path, NULL);
>
>> + realpath(dgram_address->unix_addr.sun_path, NULL);
>> +
>> + EXPECT_NE(NULL, absolute_path)
>> + {
>> + TH_LOG("realpath() failed: %s", strerror(errno));
>> + return;
>> + }
>> +
>> + log_match_cursor =
>> + stpncpy(log_match,
>> + REGEX_LANDLOCK_PREFIX
>> + " blockers=scope\\.pathname_unix_socket path=\"",
>> + log_match_remaining);
>> + log_match_remaining =
>> + sizeof(log_match) - (log_match_cursor - log_match);
>> + ASSERT_NE(0, log_match_remaining);
>> + log_match_cursor = regex_escape(absolute_path, log_match_cursor,
>> + log_match_remaining);
>> + free(absolute_path);
>> + if (log_match_cursor < 0) {
>> + TH_LOG("regex_escape() failed (buffer too small)");
>> + return;
>> + }
>> + log_match_remaining =
>> + sizeof(log_match) - (log_match_cursor - log_match);
>> + ASSERT_NE(0, log_match_remaining);
>> + log_match_cursor =
>> + stpncpy(log_match_cursor, "\"$", log_match_remaining);
>> + log_match_remaining =
>> + sizeof(log_match) - (log_match_cursor - log_match);
>> + ASSERT_NE(0, log_match_remaining);
>> + }
>> +
>> + EXPECT_EQ(0, audit_match_record(self->audit_fd, AUDIT_LANDLOCK_ACCESS,
>> + log_match, NULL));
>>
>> ASSERT_EQ(1, write(pipe_parent[1], ".", 1));
>> EXPECT_EQ(0, close(dgram_client));
>> --
>> 2.52.0
>>
>>
^ permalink raw reply
* Re: [PATCH v6 6/6] docs: trusted-encryped: add PKWM as a new trust source
From: Jarkko Sakkinen @ 2026-02-01 22:29 UTC (permalink / raw)
To: Srish Srinivasan
Cc: linux-integrity, keyrings, linuxppc-dev, maddy, mpe, npiggin,
christophe.leroy, James.Bottomley, zohar, nayna, rnsastry,
linux-kernel, linux-security-module
In-Reply-To: <20260201135930.898721-7-ssrish@linux.ibm.com>
On Sun, Feb 01, 2026 at 07:29:30PM +0530, Srish Srinivasan wrote:
> From: Nayna Jain <nayna@linux.ibm.com>
>
> Update Documentation/security/keys/trusted-encrypted.rst and Documentation/
> admin-guide/kernel-parameters.txt with PowerVM Key Wrapping Module (PKWM)
> as a new trust source
>
> Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
> Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
And you are free to take 5/6 and 6/6 to a pull request if you prefer
that route.
> ---
> .../admin-guide/kernel-parameters.txt | 1 +
> .../security/keys/trusted-encrypted.rst | 50 +++++++++++++++++++
> 2 files changed, 51 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1058f2a6d6a8..aac15079b33d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7790,6 +7790,7 @@ Kernel parameters
> - "tee"
> - "caam"
> - "dcp"
> + - "pkwm"
> If not specified then it defaults to iterating through
> the trust source list starting with TPM and assigns the
> first trust source as a backend which is initialized
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index eae6a36b1c9a..ddff7c7c2582 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -81,6 +81,14 @@ safe.
> and the UNIQUE key. Default is to use the UNIQUE key, but selecting
> the OTP key can be done via a module parameter (dcp_use_otp_key).
>
> + (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
> +
> + Rooted to a unique, per-LPAR key, which is derived from a system-wide,
> + randomly generated LPAR root key. Both the per-LPAR keys and the LPAR
> + root key are stored in hypervisor-owned secure memory at runtime,
> + and the LPAR root key is additionally persisted in secure locations
> + such as the processor SEEPROMs and encrypted NVRAM.
> +
> * Execution isolation
>
> (1) TPM
> @@ -102,6 +110,14 @@ safe.
> environment. Only basic blob key encryption is executed there.
> The actual key sealing/unsealing is done on main processor/kernel space.
>
> + (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
> +
> + Fixed set of cryptographic operations done on on-chip hardware
> + cryptographic acceleration unit NX. Keys for wrapping and unwrapping
> + are managed by PowerVM Platform KeyStore, which stores keys in an
> + isolated in-memory copy in secure hypervisor memory, as well as in a
> + persistent copy in hypervisor-encrypted NVRAM.
> +
> * Optional binding to platform integrity state
>
> (1) TPM
> @@ -129,6 +145,11 @@ safe.
> Relies on Secure/Trusted boot process (called HAB by vendor) for
> platform integrity.
>
> + (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
> +
> + Relies on secure and trusted boot process of IBM Power systems for
> + platform integrity.
> +
> * Interfaces and APIs
>
> (1) TPM
> @@ -149,6 +170,11 @@ safe.
> Vendor-specific API that is implemented as part of the DCP crypto driver in
> ``drivers/crypto/mxs-dcp.c``.
>
> + (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
> +
> + Platform Keystore has well documented interfaces in PAPR document.
> + Refer to ``Documentation/arch/powerpc/papr_hcalls.rst``
> +
> * Threat model
>
> The strength and appropriateness of a particular trust source for a given
> @@ -191,6 +217,10 @@ selected trust source:
> a dedicated hardware RNG that is independent from DCP which can be enabled
> to back the kernel RNG.
>
> + * PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
> +
> + The normal kernel random number generator is used to generate keys.
> +
> Users may override this by specifying ``trusted.rng=kernel`` on the kernel
> command-line to override the used RNG with the kernel's random number pool.
>
> @@ -321,6 +351,26 @@ Usage::
> specific to this DCP key-blob implementation. The key length for new keys is
> always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
>
> +Trusted Keys usage: PKWM
> +------------------------
> +
> +Usage::
> +
> + keyctl add trusted name "new keylen [options]" ring
> + keyctl add trusted name "load hex_blob" ring
> + keyctl print keyid
> +
> + options:
> + wrap_flags= ascii hex value of security policy requirement
> + 0x00: no secure boot requirement (default)
> + 0x01: require secure boot to be in either audit or
> + enforced mode
> + 0x02: require secure boot to be in enforced mode
> +
> +"keyctl print" returns an ASCII hex copy of the sealed key, which is in format
> +specific to PKWM key-blob implementation. The key length for new keys is
> +always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
> +
> Encrypted Keys usage
> --------------------
>
> --
> 2.47.3
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v9 01/11] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2026-02-01 22:25 UTC (permalink / raw)
To: Roberto Sassu
Cc: linux-integrity, Eric Biggers, James Bottomley, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
open list:KEYS-TRUSTED, open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <facea3621fc240ebb05dedb0127d8a514970d40d.camel@huaweicloud.com>
On Thu, Jan 29, 2026 at 05:18:55PM +0100, Roberto Sassu wrote:
> On Sun, 2026-01-25 at 21:25 +0200, Jarkko Sakkinen wrote:
> > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
> > use should be pooled rather than directly used. This both reduces
> > latency and improves its predictability.
> >
> > 2. Linux is better off overall if every subsystem uses the same source for
> > generating the random numbers required.
> >
> > Thus, unset '.get_random', which causes fallback to kernel_get_random().
> >
> > One might argue that TPM RNG should be used for the generated trusted keys,
> > so that they have matching entropy with the TPM internally generated
> > objects.
> >
> > This argument does have some weight into it but as far cryptography goes,
> > FIPS certification sets the exact bar, not which exact FIPS certified RNG
> > will be used. Thus, the rational choice is obviously to pick the lowest
> > latency path, which is kernel RNG.
> >
> > Finally, there is an actual defence in depth benefit when using kernel RNG
> > as it helps to mitigate TPM firmware bugs concerning RNG implementation,
> > given the obfuscation by the other entropy sources.
> >
> > Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > v7:
> > - A new patch. Simplifies follow up patches.
> > ---
> > security/keys/trusted-keys/trusted_tpm1.c | 16 ++++++++++------
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> > index 636acb66a4f6..7ce7e31bcdfb 100644
> > --- a/security/keys/trusted-keys/trusted_tpm1.c
> > +++ b/security/keys/trusted-keys/trusted_tpm1.c
> > @@ -6,6 +6,16 @@
> > * See Documentation/security/keys/trusted-encrypted.rst
> > */
> >
> > +/**
> > + * DOC: Random Number Generation
> > + *
> > + * tpm_get_random() was previously used here as the RNG in order to have equal
> > + * entropy with the objects fully inside the TPM. However, as far as goes,
> > + * kernel RNG is equally fine, as long as long as it is FIPS certified. Also,
> > + * using kernel RNG has the benefit of mitigating bugs in the TPM firmware
> > + * associated with the RNG.
> > + */
>
> If we switch to the kernel RNG that is better, and the TPM one is
> flawed, I guess we are going to have big problems anyway, since the TPM
> random number generator is used by the TPM itself internally.
>
> I think it makes sense to leave as it is.
There's neither really formal case for not doing this unless the random
number provided by TPM would be opaque to kernel because as soon as CPU
touches it, the "risk" matches kernel RNG generated random number.
These change do have a measurable benefit as they objectively decrease
TPM traffic.
And as we probably know, security certifications do not really apply
simply by using TPM RNG.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking
From: Eric Biggers @ 2026-02-01 20:12 UTC (permalink / raw)
To: David Howells
Cc: =?UTF-8?q?Mihai-Drosi=20C=C3=A2ju?=, linux, arnd, arnout, atomlin,
bigeasy, chleroy, christian, corbet, coxu, da.gomez, da.gomez,
dmitry.kasatkin, eric.snowberg, f.gruenbichler, jmorris, kpcyrd,
linux-arch, linux-doc, linux-integrity, linux-kbuild,
linux-kernel, linux-modules, linux-security-module, linuxppc-dev,
lkp, maddy, mattia, mcgrof, mpe, nathan, naveen,
nicolas.bouchinet, nicolas.schier, npiggin, nsc, paul, petr.pavlu,
roberto.sassu, samitolvanen, serge, xiujianfeng, zohar
In-Reply-To: <2316630.1769965788@warthog.procyon.org.uk>
On Sun, Feb 01, 2026 at 05:09:48PM +0000, David Howells wrote:
> Mihai-Drosi Câju <mcaju95@gmail.com> wrote:
>
> > > The current signature-based module integrity checking has some drawbacks
> > in combination with reproducible builds. Either the module signing key
> > is generated at build time, which makes the build unreproducible, or a
> > static signing key is used, which precludes rebuilds by third parties
> > and makes the whole build and packaging process much more complicated.
>
> There is another issue too: If you have a static private key that you use to
> sign modules (and probably other things), someone will likely give you a GPL
> request to get it.
>
> One advantage of using a transient key every build and deleting it after is
> that no one has the key.
>
> One other thing to remember: security is *meant* to get in the way. That's
> the whole point of it.
>
> However, IANAL.
>
> David
It sounds like hash-based module authentication is just better, then.
If the full set of authentic modules is known at kernel build time, then
signatures are unnecessary to verify their authenticity: a list of
hashes built into the kernel image is perfectly sufficient.
(This patchset actually gets a little fancy and makes it a Merkle tree
root. But it could be simplified to just a list of hashes.)
With that being the case, why is there still effort being put into
adding more features to module signing? I would think efforts should be
focused on hash-based module authentication, i.e. this patchset.
- Eric
^ permalink raw reply
* Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking
From: David Howells @ 2026-02-01 17:09 UTC (permalink / raw)
To: =?UTF-8?q?Mihai-Drosi=20C=C3=A2ju?=
Cc: dhowells, linux, arnd, arnout, atomlin, bigeasy, chleroy,
christian, corbet, coxu, da.gomez, da.gomez, dmitry.kasatkin,
eric.snowberg, f.gruenbichler, jmorris, kpcyrd, linux-arch,
linux-doc, linux-integrity, linux-kbuild, linux-kernel,
linux-modules, linux-security-module, linuxppc-dev, lkp, maddy,
mattia, mcgrof, mpe, nathan, naveen, nicolas.bouchinet,
nicolas.schier, npiggin, nsc, paul, petr.pavlu, roberto.sassu,
samitolvanen, serge, xiujianfeng, zohar
In-Reply-To: <20260131073636.65494-1-mcaju95@gmail.com>
Mihai-Drosi Câju <mcaju95@gmail.com> wrote:
> > The current signature-based module integrity checking has some drawbacks
> in combination with reproducible builds. Either the module signing key
> is generated at build time, which makes the build unreproducible, or a
> static signing key is used, which precludes rebuilds by third parties
> and makes the whole build and packaging process much more complicated.
There is another issue too: If you have a static private key that you use to
sign modules (and probably other things), someone will likely give you a GPL
request to get it.
One advantage of using a transient key every build and deleting it after is
that no one has the key.
One other thing to remember: security is *meant* to get in the way. That's
the whole point of it.
However, IANAL.
David
^ permalink raw reply
* Re: [PATCH v4 00/17] module: Introduce hash-based integrity checking
From: Thomas Weißschuh @ 2026-02-01 16:22 UTC (permalink / raw)
To: Mihai-Drosi Câju
Cc: arnd, arnout, atomlin, bigeasy, chleroy, christian, corbet, coxu,
da.gomez, da.gomez, dmitry.kasatkin, eric.snowberg,
f.gruenbichler, jmorris, kpcyrd, linux-arch, linux-doc,
linux-integrity, linux-kbuild, linux-kernel, linux-modules,
linux-security-module, linuxppc-dev, lkp, maddy, mattia, mcgrof,
mpe, nathan, naveen, nicolas.bouchinet, nicolas.schier, npiggin,
nsc, paul, petr.pavlu, roberto.sassu, samitolvanen, serge,
xiujianfeng, zohar
In-Reply-To: <20260131073636.65494-1-mcaju95@gmail.com>
Hi Mihai-Drosi,
thanks for taking an interest into these patches!
On 2026-01-31 09:36:36+0200, Mihai-Drosi Câju wrote:
> > The current signature-based module integrity checking has some drawbacks
> > in combination with reproducible builds. Either the module signing key
> > is generated at build time, which makes the build unreproducible, or a
> > static signing key is used, which precludes rebuilds by third parties
> > and makes the whole build and packaging process much more complicated.
>
> I think there is a middle ground where the module signing key is generated
> using a key derivation function that has as an input a deterministic value
> on the build host, such as /etc/machine-id . The problem with this approach
> is that only hosts knowing the value will be able to reproduce the build.
The goal is to make the distro kernel packages rebuildable by the
general public. Any involvement of secret values will break this goal.
> Maybe this is a solution to NixOS secret management? Introduce minimal
> impurity as a cryptographic seed and derive the rest of the secrets using
> something like Argon2(seed, key_uuid).
I am not familiar with NixOS and its secret management.
This patchset serves a wider audience.
> There might be another approach to code integrity rather than step-by-step
> reproducibility. One may exploit the very cryptographic primitives that make
> reproducibility hard to ensure that reproducibility is most likely valid.
>
> For example, the module signing issue, the build host publishes four artifacts:
> * The source-code
> * The compiled and signed binary
> * The build environment
> * Its public key
>
> Now, we don't need to sign with the private key to know that building the source
> code using the specific build environment and signing the result with the private
> key will result in the claimed binary. We can just compile and verify with the
> public key.
This could work if the goal is only to verify the reproducibility of a
single, signed-en-bloc artifact. But we also need to handle vmlinux which
contains the corresponding public key. It would need different handling.
We can add some special logic to strip that public key before
comparision. But then vmlinux might be compressed or wrapped in some
other format. Another whole collection of special logic.
(...)
Thomas
^ permalink raw reply
* Re: [RFC PATCH v3 6/8] selftests/landlock: Add tests for UDP sendmsg
From: Tingmao Wang @ 2026-02-01 16:19 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Mickaël Salaün, Günther Noack,
linux-security-module, Mikhail Ivanov, konstantin.meskhidze,
netdev
In-Reply-To: <20251212163704.142301-7-matthieu@buffet.re>
Hi Matthieu,
I noticed in passing that
On 12/12/25 16:37, Matthieu Buffet wrote:
> [...]
> + EXPECT_EQ(-EACCES, sendto_variant(sock_fd, &self->srv0, "A", 1, 0));
> + EXPECT_EQ(0, matches_log_prot(self->audit_fd, "net.sendto_udp", "daddr",
> + variant->addr, "dest"));
net.sendto_udp should probably be net\.sendto_udp
> +
> + EXPECT_EQ(0, audit_count_records(self->audit_fd, &records));
> + EXPECT_EQ(0, records.access);
> + EXPECT_EQ(1, records.domain);
> +
> + EXPECT_EQ(-EACCES, sendto_variant(sock_fd, &self->unspec_srv0, "B", 1, 0));
> + EXPECT_EQ(0, matches_log_prot(self->audit_fd, "net.sendto_udp", "daddr",
> + NULL, "dest"));
and same here
> +
> + EXPECT_EQ(0, audit_count_records(self->audit_fd, &records));
> + EXPECT_EQ(0, records.access);
> + EXPECT_EQ(0, records.domain);
> +
> + EXPECT_EQ(0, close(sock_fd));
> +}
> +
> TEST_HARNESS_MAIN
^ permalink raw reply
* Re: [PATCH v6 0/6] Extend "trusted" keys to support a new trust source named the PowerVM Key Wrapping Module (PKWM)
From: Srish Srinivasan @ 2026-02-01 15:19 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module
In-Reply-To: <20260201135930.898721-1-ssrish@linux.ibm.com>
Please ignore this series (v6).
thanks,
Srish.
On 2/1/26 7:29 PM, Srish Srinivasan wrote:
> Power11 has introduced a feature called the PowerVM Key Wrapping Module
> (PKWM), where PowerVM in combination with Power LPAR Platform KeyStore
> (PLPKS) [1] supports a new feature called "Key Wrapping" [2] to protect
> user secrets by wrapping them using a hypervisor generated wrapping key.
> This wrapping key is an AES-GCM-256 symmetric key that is stored as an
> object in the PLPKS. It has policy based protections that prevents it from
> being read out or exposed to the user. This wrapping key can then be used
> by the OS to wrap or unwrap secrets via hypervisor calls.
>
> This patchset intends to add the PKWM, which is a combination of IBM
> PowerVM and PLPKS, as a new trust source for trusted keys. The wrapping key
> does not exist by default and its generation is requested by the kernel at
> the time of PKWM initialization. This key is then persisted by the PKWM and
> is used for wrapping any kernel provided key, and is never exposed to the
> user. The kernel is aware of only the label to this wrapping key.
>
> Along with the PKWM implementation, this patchset includes two preparatory
> patches: one fixing the kernel-doc inconsistencies in the PLPKS code and
> another reorganizing PLPKS config variables in the sysfs.
>
> Changelog:
>
> v6:
>
> * Patch 1 to Patch 3:
> - Add Nayna's Tested-by tag
> * Patch 4
> - Fix build error reported by kernel test robot <lkp@intel.com>
> - Add Nayna's Tested-by tag
> * Patch 5
> - Add Nayna's Tested-by tag
>
> v5:
>
> * Patch 1 to Patch 3:
> - Add Nayna's Reviewed-by tag
> * Patch 4:
> - Fix build error identified by chleroy@kernel.org
> - Add Nayna's Reviewed-by tag
> * Patch 5:
> - Add Reviewed-by tags from Nayna and Jarkko
>
> v4:
>
> * Patch 5:
> - Add a per-backend private data pointer in trusted_key_options
> to store a pointer to the backend-specific options structure
> - Minor clean-up
>
> v3:
>
> * Patch 2:
> - Add Mimi's Reviewed-by tag
> * Patch 4:
> - Minor tweaks to some print statements
> - Fix typos
> * Patch 5:
> - Fix typos
> - Add Mimi's Reviewed-by tag
> * Patch 6:
> - Add Mimi's Reviewed-by tag
>
> v2:
>
> * Patch 2:
> - Fix build warning detected by the kernel test bot
> * Patch 5:
> - Use pr_debug inside dump_options
> - Replace policyhande with wrap_flags inside dump_options
> - Provide meaningful error messages with error codes
>
> Nayna Jain (1):
> docs: trusted-encryped: add PKWM as a new trust source
>
> Srish Srinivasan (5):
> pseries/plpks: fix kernel-doc comment inconsistencies
> powerpc/pseries: move the PLPKS config inside its own sysfs directory
> pseries/plpks: expose PowerVM wrapping features via the sysfs
> pseries/plpks: add HCALLs for PowerVM Key Wrapping Module
> keys/trusted_keys: establish PKWM as a trusted source
>
> .../ABI/testing/sysfs-firmware-plpks | 58 ++
> Documentation/ABI/testing/sysfs-secvar | 65 --
> .../admin-guide/kernel-parameters.txt | 1 +
> Documentation/arch/powerpc/papr_hcalls.rst | 43 ++
> .../security/keys/trusted-encrypted.rst | 50 ++
> MAINTAINERS | 9 +
> arch/powerpc/include/asm/hvcall.h | 4 +-
> arch/powerpc/include/asm/plpks.h | 95 +--
> arch/powerpc/include/asm/secvar.h | 1 -
> arch/powerpc/kernel/secvar-sysfs.c | 21 +-
> arch/powerpc/platforms/pseries/Makefile | 2 +-
> arch/powerpc/platforms/pseries/plpks-secvar.c | 29 -
> arch/powerpc/platforms/pseries/plpks-sysfs.c | 96 +++
> arch/powerpc/platforms/pseries/plpks.c | 688 +++++++++++++++++-
> include/keys/trusted-type.h | 7 +-
> include/keys/trusted_pkwm.h | 33 +
> 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 | 190 +++++
> 20 files changed, 1207 insertions(+), 201 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-plpks
> create mode 100644 arch/powerpc/platforms/pseries/plpks-sysfs.c
> create mode 100644 include/keys/trusted_pkwm.h
> create mode 100644 security/keys/trusted-keys/trusted_pkwm.c
>
^ permalink raw reply
* [PATCH v6 4/6] pseries/plpks: add HCALLs for PowerVM Key Wrapping Module
From: Srish Srinivasan @ 2026-02-01 13:59 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module,
ssrish
In-Reply-To: <20260201135930.898721-1-ssrish@linux.ibm.com>
The hypervisor generated wrapping key is an AES-GCM-256 symmetric key which
is stored in a non-volatile, secure, and encrypted storage called the Power
LPAR Platform KeyStore. It has policy based protections that prevent it
from being read out or exposed to the user.
Implement H_PKS_GEN_KEY, H_PKS_WRAP_OBJECT, and H_PKS_UNWRAP_OBJECT HCALLs
to enable using the PowerVM Key Wrapping Module (PKWM) as a new trust
source for trusted keys. Disallow H_PKS_READ_OBJECT, H_PKS_SIGNED_UPDATE,
and H_PKS_WRITE_OBJECT for objects with the 'wrapping key' policy set.
Capture the availability status for the H_PKS_WRAP_OBJECT interface.
Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
---
Documentation/arch/powerpc/papr_hcalls.rst | 43 +++
arch/powerpc/include/asm/plpks.h | 10 +
arch/powerpc/platforms/pseries/plpks.c | 344 ++++++++++++++++++++-
3 files changed, 395 insertions(+), 2 deletions(-)
diff --git a/Documentation/arch/powerpc/papr_hcalls.rst b/Documentation/arch/powerpc/papr_hcalls.rst
index 805e1cb9bab9..14e39f095a1c 100644
--- a/Documentation/arch/powerpc/papr_hcalls.rst
+++ b/Documentation/arch/powerpc/papr_hcalls.rst
@@ -300,6 +300,49 @@ H_HTM supports setup, configuration, control and dumping of Hardware Trace
Macro (HTM) function and its data. HTM buffer stores tracing data for functions
like core instruction, core LLAT and nest.
+**H_PKS_GEN_KEY**
+
+| Input: authorization, objectlabel, objectlabellen, policy, out, outlen
+| Out: *Hypervisor Generated Key, or None when the wrapping key policy is set*
+| Return Value: *H_SUCCESS, H_Function, H_State, H_R_State, H_Parameter, H_P2,
+ H_P3, H_P4, H_P5, H_P6, H_Authority, H_Nomem, H_Busy, H_Resource,
+ H_Aborted*
+
+H_PKS_GEN_KEY is used to have the hypervisor generate a new random key.
+This key is stored as an object in the Power LPAR Platform KeyStore with
+the provided object label. With the wrapping key policy set the key is only
+visible to the hypervisor, while the key's label would still be visible to
+the user. Generation of wrapping keys is supported only for a key size of
+32 bytes.
+
+**H_PKS_WRAP_OBJECT**
+
+| Input: authorization, wrapkeylabel, wrapkeylabellen, objectwrapflags, in,
+| inlen, out, outlen, continue-token
+| Out: *continue-token, byte size of wrapped object, wrapped object*
+| Return Value: *H_SUCCESS, H_Function, H_State, H_R_State, H_Parameter, H_P2,
+ H_P3, H_P4, H_P5, H_P6, H_P7, H_P8, H_P9, H_Authority, H_Invalid_Key,
+ H_NOT_FOUND, H_Busy, H_LongBusy, H_Aborted*
+
+H_PKS_WRAP_OBJECT is used to wrap an object using a wrapping key stored in the
+Power LPAR Platform KeyStore and return the wrapped object to the caller. The
+caller provides a label to a wrapping key with the 'wrapping key' policy set,
+which must have been previously created with H_PKS_GEN_KEY. The provided object
+is then encrypted with the wrapping key and additional metadata and the result
+is returned to the caller.
+
+
+**H_PKS_UNWRAP_OBJECT**
+
+| Input: authorization, objectwrapflags, in, inlen, out, outlen, continue-token
+| Out: *continue-token, byte size of unwrapped object, unwrapped object*
+| Return Value: *H_SUCCESS, H_Function, H_State, H_R_State, H_Parameter, H_P2,
+ H_P3, H_P4, H_P5, H_P6, H_P7, H_Authority, H_Unsupported, H_Bad_Data,
+ H_NOT_FOUND, H_Invalid_Key, H_Busy, H_LongBusy, H_Aborted*
+
+H_PKS_UNWRAP_OBJECT is used to unwrap an object that was previously warapped with
+H_PKS_WRAP_OBJECT.
+
References
==========
.. [1] "Power Architecture Platform Reference"
diff --git a/arch/powerpc/include/asm/plpks.h b/arch/powerpc/include/asm/plpks.h
index 8f034588fdf7..e87f90e40d4e 100644
--- a/arch/powerpc/include/asm/plpks.h
+++ b/arch/powerpc/include/asm/plpks.h
@@ -113,6 +113,16 @@ void plpks_early_init_devtree(void);
int plpks_populate_fdt(void *fdt);
int plpks_config_create_softlink(struct kobject *from);
+
+bool plpks_wrapping_is_supported(void);
+
+int plpks_gen_wrapping_key(void);
+
+int plpks_wrap_object(u8 **input_buf, u32 input_len, u16 wrap_flags,
+ u8 **output_buf, u32 *output_len);
+
+int plpks_unwrap_object(u8 **input_buf, u32 input_len,
+ u8 **output_buf, u32 *output_len);
#else // CONFIG_PSERIES_PLPKS
static inline bool plpks_is_available(void) { return false; }
static inline u16 plpks_get_passwordlen(void) { BUILD_BUG(); }
diff --git a/arch/powerpc/platforms/pseries/plpks.c b/arch/powerpc/platforms/pseries/plpks.c
index 4a08f51537c8..23e4e2a922fc 100644
--- a/arch/powerpc/platforms/pseries/plpks.c
+++ b/arch/powerpc/platforms/pseries/plpks.c
@@ -9,6 +9,32 @@
#define pr_fmt(fmt) "plpks: " fmt
+#define PLPKS_WRAPKEY_COMPONENT "PLPKSWR"
+#define PLPKS_WRAPKEY_NAME "default-wrapping-key"
+
+/*
+ * To 4K align the {input, output} buffers to the {UN}WRAP H_CALLs
+ */
+#define PLPKS_WRAPPING_BUF_ALIGN 4096
+
+/*
+ * To ensure the output buffer's length is at least 1024 bytes greater
+ * than the input buffer's length during the WRAP H_CALL
+ */
+#define PLPKS_WRAPPING_BUF_DIFF 1024
+
+#define PLPKS_WRAP_INTERFACE_BIT 3
+#define PLPKS_WRAPPING_KEY_LENGTH 32
+
+#define WRAPFLAG_BE_BIT_SET(be_bit) \
+ BIT_ULL(63 - (be_bit))
+
+#define WRAPFLAG_BE_GENMASK(be_bit_hi, be_bit_lo) \
+ GENMASK_ULL(63 - (be_bit_hi), 63 - (be_bit_lo))
+
+#define WRAPFLAG_BE_FIELD_PREP(be_bit_hi, be_bit_lo, val) \
+ FIELD_PREP(WRAPFLAG_BE_GENMASK(be_bit_hi, be_bit_lo), (val))
+
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/io.h>
@@ -19,6 +45,7 @@
#include <linux/of_fdt.h>
#include <linux/libfdt.h>
#include <linux/memblock.h>
+#include <linux/bitfield.h>
#include <asm/hvcall.h>
#include <asm/machdep.h>
#include <asm/plpks.h>
@@ -39,6 +66,7 @@ static u32 supportedpolicies;
static u32 maxlargeobjectsize;
static u64 signedupdatealgorithms;
static u64 wrappingfeatures;
+static bool wrapsupport;
struct plpks_auth {
u8 version;
@@ -283,6 +311,7 @@ static int _plpks_get_config(void)
maxlargeobjectsize = be32_to_cpu(config->maxlargeobjectsize);
signedupdatealgorithms = be64_to_cpu(config->signedupdatealgorithms);
wrappingfeatures = be64_to_cpu(config->wrappingfeatures);
+ wrapsupport = config->flags & PPC_BIT8(PLPKS_WRAP_INTERFACE_BIT);
// Validate that the numbers we get back match the requirements of the spec
if (maxpwsize < 32) {
@@ -614,6 +643,9 @@ int plpks_signed_update_var(struct plpks_var *var, u64 flags)
if (!(var->policy & PLPKS_SIGNEDUPDATE))
return -EINVAL;
+ if (var->policy & PLPKS_WRAPPINGKEY)
+ return -EINVAL;
+
// Signed updates need the component to be NULL.
if (var->component)
return -EINVAL;
@@ -696,6 +728,9 @@ int plpks_write_var(struct plpks_var var)
if (var.policy & PLPKS_SIGNEDUPDATE)
return -EINVAL;
+ if (var.policy & PLPKS_WRAPPINGKEY)
+ return -EINVAL;
+
auth = construct_auth(PLPKS_OS_OWNER);
if (IS_ERR(auth))
return PTR_ERR(auth);
@@ -790,6 +825,9 @@ static int plpks_read_var(u8 consumer, struct plpks_var *var)
if (var->namelen > PLPKS_MAX_NAME_SIZE)
return -EINVAL;
+ if (var->policy & PLPKS_WRAPPINGKEY)
+ return -EINVAL;
+
auth = construct_auth(consumer);
if (IS_ERR(auth))
return PTR_ERR(auth);
@@ -845,8 +883,310 @@ static int plpks_read_var(u8 consumer, struct plpks_var *var)
}
/**
- * plpks_read_os_var() - Fetch the data for the specified variable that is
- * owned by the OS consumer.
+ * plpks_wrapping_is_supported() - Get the H_PKS_WRAP_OBJECT interface
+ * availability status for the LPAR.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * sets bit 3 of the flags variable in the PLPKS config structure if the
+ * H_PKS_WRAP_OBJECT interface is supported.
+ *
+ * Returns: true if the H_PKS_WRAP_OBJECT interface is supported, false if not.
+ */
+bool plpks_wrapping_is_supported(void)
+{
+ return wrapsupport;
+}
+EXPORT_SYMBOL_GPL(plpks_wrapping_is_supported);
+
+/**
+ * plpks_gen_wrapping_key() - Generate a new random key with the 'wrapping key'
+ * policy set.
+ *
+ * The H_PKS_GEN_KEY HCALL makes the hypervisor generate a new random key and
+ * store the key in a PLPKS object with the provided object label. With the
+ * 'wrapping key' policy set, only the label to the newly generated random key
+ * would be visible to the user.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if PLPKS modification is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid object label parameter
+ * if invalid object label len parameter
+ * if invalid or unsupported policy declaration
+ * if invalid output buffer parameter
+ * if invalid output buffer length parameter
+ * -EPERM if access is denied
+ * -ENOMEM if there is inadequate memory to perform this operation
+ * -EBUSY if unable to handle the request
+ * -EEXIST if the object label already exists
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
+int plpks_gen_wrapping_key(void)
+{
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE] = { 0 };
+ struct plpks_auth *auth;
+ struct label *label;
+ int rc = 0, pseries_status = 0;
+ struct plpks_var var = {
+ .name = PLPKS_WRAPKEY_NAME,
+ .namelen = strlen(var.name),
+ .policy = PLPKS_WRAPPINGKEY,
+ .os = PLPKS_VAR_LINUX,
+ .component = PLPKS_WRAPKEY_COMPONENT
+ };
+
+ auth = construct_auth(PLPKS_OS_OWNER);
+ if (IS_ERR(auth))
+ return PTR_ERR(auth);
+
+ label = construct_label(var.component, var.os, var.name, var.namelen);
+ if (IS_ERR(label)) {
+ rc = PTR_ERR(label);
+ goto out;
+ }
+
+ rc = plpar_hcall(H_PKS_GEN_KEY, retbuf,
+ virt_to_phys(auth), virt_to_phys(label),
+ label->size, var.policy,
+ NULL, PLPKS_WRAPPING_KEY_LENGTH);
+
+ if (!rc)
+ rc = plpks_confirm_object_flushed(label, auth);
+
+ pseries_status = rc;
+ rc = pseries_status_to_err(rc);
+
+ if (rc && rc != -EEXIST) {
+ pr_err("H_PKS_GEN_KEY failed. pseries_status=%d, rc=%d",
+ pseries_status, rc);
+ } else {
+ rc = 0;
+ }
+
+ kfree(label);
+out:
+ kfree(auth);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(plpks_gen_wrapping_key);
+
+/**
+ * plpks_wrap_object() - Wrap an object using the default wrapping key stored in
+ * the PLPKS.
+ * @input_buf: buffer containing the data to be wrapped
+ * @input_len: length of the input buffer
+ * @wrap_flags: object wrapping flags
+ * @output_buf: buffer to store the wrapped data
+ * @output_len: length of the output buffer
+ *
+ * The H_PKS_WRAP_OBJECT HCALL wraps an object using a wrapping key stored in
+ * the PLPKS and returns the wrapped object to the caller. The caller provides a
+ * label to the wrapping key with the 'wrapping key' policy set that must have
+ * been previously created with the H_PKS_GEN_KEY HCALL. The provided object is
+ * then encrypted with the wrapping key and additional metadata and the result
+ * is returned to the user. The metadata includes the wrapping algorithm and the
+ * wrapping key name so those parameters are not required during unwrap.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if PLPKS modification is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid wrapping key label parameter
+ * if invalid wrapping key label length parameter
+ * if invalid or unsupported object wrapping flags
+ * if invalid input buffer parameter
+ * if invalid input buffer length parameter
+ * if invalid output buffer parameter
+ * if invalid output buffer length parameter
+ * if invalid continue token parameter
+ * if the wrapping key is not compatible with the wrapping
+ * algorithm
+ * -EPERM if access is denied
+ * -ENOENT if the requested wrapping key was not found
+ * -EBUSY if unable to handle the request or long running operation
+ * initiated, retry later.
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
+int plpks_wrap_object(u8 **input_buf, u32 input_len, u16 wrap_flags,
+ u8 **output_buf, u32 *output_len)
+{
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE] = { 0 };
+ struct plpks_auth *auth;
+ struct label *label;
+ u64 continuetoken = 0;
+ u64 objwrapflags = 0;
+ int rc = 0, pseries_status = 0;
+ bool sb_audit_or_enforce_bit = wrap_flags & BIT(0);
+ bool sb_enforce_bit = wrap_flags & BIT(1);
+ struct plpks_var var = {
+ .name = PLPKS_WRAPKEY_NAME,
+ .namelen = strlen(var.name),
+ .os = PLPKS_VAR_LINUX,
+ .component = PLPKS_WRAPKEY_COMPONENT
+ };
+
+ auth = construct_auth(PLPKS_OS_OWNER);
+ if (IS_ERR(auth))
+ return PTR_ERR(auth);
+
+ label = construct_label(var.component, var.os, var.name, var.namelen);
+ if (IS_ERR(label)) {
+ rc = PTR_ERR(label);
+ goto out;
+ }
+
+ /* Set the consumer password requirement bit. A must have. */
+ objwrapflags |= WRAPFLAG_BE_BIT_SET(3);
+
+ /* Set the wrapping algorithm bit. Just one algorithm option for now */
+ objwrapflags |= WRAPFLAG_BE_FIELD_PREP(60, 63, 0x1);
+
+ if (sb_audit_or_enforce_bit & sb_enforce_bit) {
+ pr_err("Cannot set both audit/enforce and enforce bits.");
+ rc = -EINVAL;
+ goto out_free_label;
+ } else if (sb_audit_or_enforce_bit) {
+ objwrapflags |= WRAPFLAG_BE_BIT_SET(1);
+ } else if (sb_enforce_bit) {
+ objwrapflags |= WRAPFLAG_BE_BIT_SET(2);
+ }
+
+ *output_len = input_len + PLPKS_WRAPPING_BUF_DIFF;
+
+ *output_buf = kzalloc(ALIGN(*output_len, PLPKS_WRAPPING_BUF_ALIGN),
+ GFP_KERNEL);
+ if (!(*output_buf)) {
+ pr_err("Output buffer allocation failed. Returning -ENOMEM.");
+ rc = -ENOMEM;
+ goto out_free_label;
+ }
+
+ do {
+ rc = plpar_hcall9(H_PKS_WRAP_OBJECT, retbuf,
+ virt_to_phys(auth), virt_to_phys(label),
+ label->size, objwrapflags,
+ virt_to_phys(*input_buf), input_len,
+ virt_to_phys(*output_buf), *output_len,
+ continuetoken);
+
+ continuetoken = retbuf[0];
+ pseries_status = rc;
+ rc = pseries_status_to_err(rc);
+ } while (rc == -EBUSY);
+
+ if (rc) {
+ pr_err("H_PKS_WRAP_OBJECT failed. pseries_status=%d, rc=%d",
+ pseries_status, rc);
+ kfree(*output_buf);
+ *output_buf = NULL;
+ } else {
+ *output_len = retbuf[1];
+ }
+
+out_free_label:
+ kfree(label);
+out:
+ kfree(auth);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(plpks_wrap_object);
+
+/**
+ * plpks_unwrap_object() - Unwrap an object using the default wrapping key
+ * stored in the PLPKS.
+ * @input_buf: buffer containing the data to be unwrapped
+ * @input_len: length of the input buffer
+ * @output_buf: buffer to store the unwrapped data
+ * @output_len: length of the output buffer
+ *
+ * The H_PKS_UNWRAP_OBJECT HCALL unwraps an object that was previously wrapped
+ * using the H_PKS_WRAP_OBJECT HCALL.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if PLPKS modification is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid or unsupported object unwrapping flags
+ * if invalid input buffer parameter
+ * if invalid input buffer length parameter
+ * if invalid output buffer parameter
+ * if invalid output buffer length parameter
+ * if invalid continue token parameter
+ * if the wrapping key is not compatible with the wrapping
+ * algorithm
+ * if the wrapped object's format is not supported
+ * if the wrapped object is invalid
+ * -EPERM if access is denied
+ * -ENOENT if the wrapping key for the provided object was not found
+ * -EBUSY if unable to handle the request or long running operation
+ * initiated, retry later.
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
+int plpks_unwrap_object(u8 **input_buf, u32 input_len, u8 **output_buf,
+ u32 *output_len)
+{
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE] = { 0 };
+ struct plpks_auth *auth;
+ u64 continuetoken = 0;
+ u64 objwrapflags = 0;
+ int rc = 0, pseries_status = 0;
+
+ auth = construct_auth(PLPKS_OS_OWNER);
+ if (IS_ERR(auth))
+ return PTR_ERR(auth);
+
+ *output_len = input_len - PLPKS_WRAPPING_BUF_DIFF;
+ *output_buf = kzalloc(ALIGN(*output_len, PLPKS_WRAPPING_BUF_ALIGN),
+ GFP_KERNEL);
+ if (!(*output_buf)) {
+ pr_err("Output buffer allocation failed. Returning -ENOMEM.");
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ do {
+ rc = plpar_hcall9(H_PKS_UNWRAP_OBJECT, retbuf,
+ virt_to_phys(auth), objwrapflags,
+ virt_to_phys(*input_buf), input_len,
+ virt_to_phys(*output_buf), *output_len,
+ continuetoken);
+
+ continuetoken = retbuf[0];
+ pseries_status = rc;
+ rc = pseries_status_to_err(rc);
+ } while (rc == -EBUSY);
+
+ if (rc) {
+ pr_err("H_PKS_UNWRAP_OBJECT failed. pseries_status=%d, rc=%d",
+ pseries_status, rc);
+ kfree(*output_buf);
+ *output_buf = NULL;
+ } else {
+ *output_len = retbuf[1];
+ }
+
+out:
+ kfree(auth);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(plpks_unwrap_object);
+
+/**
+ * plpks_read_os_var() - Fetch the data for the specified variable that is owned
+ * by the OS consumer.
* @var: variable to be read from the PLPKS
*
* The consumer or the owner of the object is the os kernel. The
--
2.47.3
^ permalink raw reply related
* [PATCH v6 6/6] docs: trusted-encryped: add PKWM as a new trust source
From: Srish Srinivasan @ 2026-02-01 13:59 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module,
ssrish
In-Reply-To: <20260201135930.898721-1-ssrish@linux.ibm.com>
From: Nayna Jain <nayna@linux.ibm.com>
Update Documentation/security/keys/trusted-encrypted.rst and Documentation/
admin-guide/kernel-parameters.txt with PowerVM Key Wrapping Module (PKWM)
as a new trust source
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
---
.../admin-guide/kernel-parameters.txt | 1 +
.../security/keys/trusted-encrypted.rst | 50 +++++++++++++++++++
2 files changed, 51 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1058f2a6d6a8..aac15079b33d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7790,6 +7790,7 @@ Kernel parameters
- "tee"
- "caam"
- "dcp"
+ - "pkwm"
If not specified then it defaults to iterating through
the trust source list starting with TPM and assigns the
first trust source as a backend which is initialized
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index eae6a36b1c9a..ddff7c7c2582 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -81,6 +81,14 @@ safe.
and the UNIQUE key. Default is to use the UNIQUE key, but selecting
the OTP key can be done via a module parameter (dcp_use_otp_key).
+ (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
+
+ Rooted to a unique, per-LPAR key, which is derived from a system-wide,
+ randomly generated LPAR root key. Both the per-LPAR keys and the LPAR
+ root key are stored in hypervisor-owned secure memory at runtime,
+ and the LPAR root key is additionally persisted in secure locations
+ such as the processor SEEPROMs and encrypted NVRAM.
+
* Execution isolation
(1) TPM
@@ -102,6 +110,14 @@ safe.
environment. Only basic blob key encryption is executed there.
The actual key sealing/unsealing is done on main processor/kernel space.
+ (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
+
+ Fixed set of cryptographic operations done on on-chip hardware
+ cryptographic acceleration unit NX. Keys for wrapping and unwrapping
+ are managed by PowerVM Platform KeyStore, which stores keys in an
+ isolated in-memory copy in secure hypervisor memory, as well as in a
+ persistent copy in hypervisor-encrypted NVRAM.
+
* Optional binding to platform integrity state
(1) TPM
@@ -129,6 +145,11 @@ safe.
Relies on Secure/Trusted boot process (called HAB by vendor) for
platform integrity.
+ (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
+
+ Relies on secure and trusted boot process of IBM Power systems for
+ platform integrity.
+
* Interfaces and APIs
(1) TPM
@@ -149,6 +170,11 @@ safe.
Vendor-specific API that is implemented as part of the DCP crypto driver in
``drivers/crypto/mxs-dcp.c``.
+ (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
+
+ Platform Keystore has well documented interfaces in PAPR document.
+ Refer to ``Documentation/arch/powerpc/papr_hcalls.rst``
+
* Threat model
The strength and appropriateness of a particular trust source for a given
@@ -191,6 +217,10 @@ selected trust source:
a dedicated hardware RNG that is independent from DCP which can be enabled
to back the kernel RNG.
+ * PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)
+
+ The normal kernel random number generator is used to generate keys.
+
Users may override this by specifying ``trusted.rng=kernel`` on the kernel
command-line to override the used RNG with the kernel's random number pool.
@@ -321,6 +351,26 @@ Usage::
specific to this DCP key-blob implementation. The key length for new keys is
always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+Trusted Keys usage: PKWM
+------------------------
+
+Usage::
+
+ keyctl add trusted name "new keylen [options]" ring
+ keyctl add trusted name "load hex_blob" ring
+ keyctl print keyid
+
+ options:
+ wrap_flags= ascii hex value of security policy requirement
+ 0x00: no secure boot requirement (default)
+ 0x01: require secure boot to be in either audit or
+ enforced mode
+ 0x02: require secure boot to be in enforced mode
+
+"keyctl print" returns an ASCII hex copy of the sealed key, which is in format
+specific to PKWM key-blob implementation. The key length for new keys is
+always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+
Encrypted Keys usage
--------------------
--
2.47.3
^ permalink raw reply related
* [PATCH v6 2/6] powerpc/pseries: move the PLPKS config inside its own sysfs directory
From: Srish Srinivasan @ 2026-02-01 13:59 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module,
ssrish
In-Reply-To: <20260201135930.898721-1-ssrish@linux.ibm.com>
The /sys/firmware/secvar/config directory represents Power LPAR Platform
KeyStore (PLPKS) configuration properties such as max_object_size, signed_
update_algorithms, supported_policies, total_size, used_space, and version.
These attributes describe the PLPKS, and not the secure boot variables
(secvars).
Create /sys/firmware/plpks directory and move the PLPKS config inside this
directory. For backwards compatibility, create a soft link from the secvar
sysfs directory to this config and emit a warning stating that the older
sysfs path has been deprecated. Separate out the plpks specific
documentation from secvar.
Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
---
.../ABI/testing/sysfs-firmware-plpks | 50 ++++++++++
Documentation/ABI/testing/sysfs-secvar | 65 -------------
arch/powerpc/include/asm/plpks.h | 5 +
arch/powerpc/include/asm/secvar.h | 1 -
arch/powerpc/kernel/secvar-sysfs.c | 21 ++---
arch/powerpc/platforms/pseries/Makefile | 2 +-
arch/powerpc/platforms/pseries/plpks-secvar.c | 29 ------
arch/powerpc/platforms/pseries/plpks-sysfs.c | 94 +++++++++++++++++++
8 files changed, 156 insertions(+), 111 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-plpks
create mode 100644 arch/powerpc/platforms/pseries/plpks-sysfs.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-plpks b/Documentation/ABI/testing/sysfs-firmware-plpks
new file mode 100644
index 000000000000..af0353f34115
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-plpks
@@ -0,0 +1,50 @@
+What: /sys/firmware/plpks/config
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: This optional directory contains read-only config attributes as
+ defined by the PLPKS implementation. All data is in ASCII
+ format.
+
+What: /sys/firmware/plpks/config/version
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Config version as reported by the hypervisor in ASCII decimal
+ format.
+
+What: /sys/firmware/plpks/config/max_object_size
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Maximum allowed size of objects in the keystore in bytes,
+ represented in ASCII decimal format.
+
+ This is not necessarily the same as the max size that can be
+ written to an update file as writes can contain more than
+ object data, you should use the size of the update file for
+ that purpose.
+
+What: /sys/firmware/plpks/config/total_size
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Total size of the PLPKS in bytes, represented in ASCII decimal
+ format.
+
+What: /sys/firmware/plpks/config/used_space
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Current space consumed by the key store, in bytes, represented
+ in ASCII decimal format.
+
+What: /sys/firmware/plpks/config/supported_policies
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Bitmask of supported policy flags by the hypervisor, represented
+ as an 8 byte hexadecimal ASCII string. Consult the hypervisor
+ documentation for what these flags are.
+
+What: /sys/firmware/plpks/config/signed_update_algorithms
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Bitmask of flags indicating which algorithms the hypervisor
+ supports for signed update of objects, represented as a 16 byte
+ hexadecimal ASCII string. Consult the hypervisor documentation
+ for what these flags mean.
diff --git a/Documentation/ABI/testing/sysfs-secvar b/Documentation/ABI/testing/sysfs-secvar
index 1016967a730f..c52a5fd15709 100644
--- a/Documentation/ABI/testing/sysfs-secvar
+++ b/Documentation/ABI/testing/sysfs-secvar
@@ -63,68 +63,3 @@ Contact: Nayna Jain <nayna@linux.ibm.com>
Description: A write-only file that is used to submit the new value for the
variable. The size of the file represents the maximum size of
the variable data that can be written.
-
-What: /sys/firmware/secvar/config
-Date: February 2023
-Contact: Nayna Jain <nayna@linux.ibm.com>
-Description: This optional directory contains read-only config attributes as
- defined by the secure variable implementation. All data is in
- ASCII format. The directory is only created if the backing
- implementation provides variables to populate it, which at
- present is only PLPKS on the pseries platform.
-
-What: /sys/firmware/secvar/config/version
-Date: February 2023
-Contact: Nayna Jain <nayna@linux.ibm.com>
-Description: Config version as reported by the hypervisor in ASCII decimal
- format.
-
- Currently only provided by PLPKS on the pseries platform.
-
-What: /sys/firmware/secvar/config/max_object_size
-Date: February 2023
-Contact: Nayna Jain <nayna@linux.ibm.com>
-Description: Maximum allowed size of objects in the keystore in bytes,
- represented in ASCII decimal format.
-
- This is not necessarily the same as the max size that can be
- written to an update file as writes can contain more than
- object data, you should use the size of the update file for
- that purpose.
-
- Currently only provided by PLPKS on the pseries platform.
-
-What: /sys/firmware/secvar/config/total_size
-Date: February 2023
-Contact: Nayna Jain <nayna@linux.ibm.com>
-Description: Total size of the PLPKS in bytes, represented in ASCII decimal
- format.
-
- Currently only provided by PLPKS on the pseries platform.
-
-What: /sys/firmware/secvar/config/used_space
-Date: February 2023
-Contact: Nayna Jain <nayna@linux.ibm.com>
-Description: Current space consumed by the key store, in bytes, represented
- in ASCII decimal format.
-
- Currently only provided by PLPKS on the pseries platform.
-
-What: /sys/firmware/secvar/config/supported_policies
-Date: February 2023
-Contact: Nayna Jain <nayna@linux.ibm.com>
-Description: Bitmask of supported policy flags by the hypervisor,
- represented as an 8 byte hexadecimal ASCII string. Consult the
- hypervisor documentation for what these flags are.
-
- Currently only provided by PLPKS on the pseries platform.
-
-What: /sys/firmware/secvar/config/signed_update_algorithms
-Date: February 2023
-Contact: Nayna Jain <nayna@linux.ibm.com>
-Description: Bitmask of flags indicating which algorithms the hypervisor
- supports for signed update of objects, represented as a 16 byte
- hexadecimal ASCII string. Consult the hypervisor documentation
- for what these flags mean.
-
- Currently only provided by PLPKS on the pseries platform.
diff --git a/arch/powerpc/include/asm/plpks.h b/arch/powerpc/include/asm/plpks.h
index f303922bf622..8829a13bfda0 100644
--- a/arch/powerpc/include/asm/plpks.h
+++ b/arch/powerpc/include/asm/plpks.h
@@ -13,6 +13,7 @@
#include <linux/types.h>
#include <linux/list.h>
+#include <linux/kobject.h>
// Object policy flags from supported_policies
#define PLPKS_OSSECBOOTAUDIT PPC_BIT32(1) // OS secure boot must be audit/enforce
@@ -107,11 +108,15 @@ u16 plpks_get_passwordlen(void);
void plpks_early_init_devtree(void);
int plpks_populate_fdt(void *fdt);
+
+int plpks_config_create_softlink(struct kobject *from);
#else // CONFIG_PSERIES_PLPKS
static inline bool plpks_is_available(void) { return false; }
static inline u16 plpks_get_passwordlen(void) { BUILD_BUG(); }
static inline void plpks_early_init_devtree(void) { }
static inline int plpks_populate_fdt(void *fdt) { BUILD_BUG(); }
+static inline int plpks_config_create_softlink(struct kobject *from)
+ { return 0; }
#endif // CONFIG_PSERIES_PLPKS
#endif // _ASM_POWERPC_PLPKS_H
diff --git a/arch/powerpc/include/asm/secvar.h b/arch/powerpc/include/asm/secvar.h
index 4828e0ab7e3c..fd5006307f2a 100644
--- a/arch/powerpc/include/asm/secvar.h
+++ b/arch/powerpc/include/asm/secvar.h
@@ -20,7 +20,6 @@ struct secvar_operations {
int (*set)(const char *key, u64 key_len, u8 *data, u64 data_size);
ssize_t (*format)(char *buf, size_t bufsize);
int (*max_size)(u64 *max_size);
- const struct attribute **config_attrs;
// NULL-terminated array of fixed variable names
// Only used if get_next() isn't provided
diff --git a/arch/powerpc/kernel/secvar-sysfs.c b/arch/powerpc/kernel/secvar-sysfs.c
index ec900bce0257..4111b21962eb 100644
--- a/arch/powerpc/kernel/secvar-sysfs.c
+++ b/arch/powerpc/kernel/secvar-sysfs.c
@@ -12,6 +12,7 @@
#include <linux/string.h>
#include <linux/of.h>
#include <asm/secvar.h>
+#include <asm/plpks.h>
#define NAME_MAX_SIZE 1024
@@ -145,19 +146,6 @@ static __init int update_kobj_size(void)
return 0;
}
-static __init int secvar_sysfs_config(struct kobject *kobj)
-{
- struct attribute_group config_group = {
- .name = "config",
- .attrs = (struct attribute **)secvar_ops->config_attrs,
- };
-
- if (secvar_ops->config_attrs)
- return sysfs_create_group(kobj, &config_group);
-
- return 0;
-}
-
static __init int add_var(const char *name)
{
struct kobject *kobj;
@@ -260,12 +248,15 @@ static __init int secvar_sysfs_init(void)
goto err;
}
- rc = secvar_sysfs_config(secvar_kobj);
+ rc = plpks_config_create_softlink(secvar_kobj);
if (rc) {
- pr_err("Failed to create config directory\n");
+ pr_err("Failed to create softlink to PLPKS config directory");
goto err;
}
+ pr_info("/sys/firmware/secvar/config is now deprecated.\n");
+ pr_info("Will be removed in future versions.\n");
+
if (secvar_ops->get_next)
rc = secvar_sysfs_load();
else
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index 931ebaa474c8..3ced289a675b 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_PAPR_SCM) += papr_scm.o
obj-$(CONFIG_PPC_SPLPAR) += vphn.o
obj-$(CONFIG_PPC_SVM) += svm.o
obj-$(CONFIG_FA_DUMP) += rtas-fadump.o
-obj-$(CONFIG_PSERIES_PLPKS) += plpks.o
+obj-$(CONFIG_PSERIES_PLPKS) += plpks.o plpks-sysfs.o
obj-$(CONFIG_PPC_SECURE_BOOT) += plpks-secvar.o
obj-$(CONFIG_PSERIES_PLPKS_SED) += plpks_sed_ops.o
obj-$(CONFIG_SUSPEND) += suspend.o
diff --git a/arch/powerpc/platforms/pseries/plpks-secvar.c b/arch/powerpc/platforms/pseries/plpks-secvar.c
index f9e9cc40c9d0..a50ff6943d80 100644
--- a/arch/powerpc/platforms/pseries/plpks-secvar.c
+++ b/arch/powerpc/platforms/pseries/plpks-secvar.c
@@ -20,33 +20,6 @@
#include <asm/secvar.h>
#include <asm/plpks.h>
-// Config attributes for sysfs
-#define PLPKS_CONFIG_ATTR(name, fmt, func) \
- static ssize_t name##_show(struct kobject *kobj, \
- struct kobj_attribute *attr, \
- char *buf) \
- { \
- return sysfs_emit(buf, fmt, func()); \
- } \
- static struct kobj_attribute attr_##name = __ATTR_RO(name)
-
-PLPKS_CONFIG_ATTR(version, "%u\n", plpks_get_version);
-PLPKS_CONFIG_ATTR(max_object_size, "%u\n", plpks_get_maxobjectsize);
-PLPKS_CONFIG_ATTR(total_size, "%u\n", plpks_get_totalsize);
-PLPKS_CONFIG_ATTR(used_space, "%u\n", plpks_get_usedspace);
-PLPKS_CONFIG_ATTR(supported_policies, "%08x\n", plpks_get_supportedpolicies);
-PLPKS_CONFIG_ATTR(signed_update_algorithms, "%016llx\n", plpks_get_signedupdatealgorithms);
-
-static const struct attribute *config_attrs[] = {
- &attr_version.attr,
- &attr_max_object_size.attr,
- &attr_total_size.attr,
- &attr_used_space.attr,
- &attr_supported_policies.attr,
- &attr_signed_update_algorithms.attr,
- NULL,
-};
-
static u32 get_policy(const char *name)
{
if ((strcmp(name, "db") == 0) ||
@@ -225,7 +198,6 @@ static const struct secvar_operations plpks_secvar_ops_static = {
.set = plpks_set_variable,
.format = plpks_secvar_format,
.max_size = plpks_max_size,
- .config_attrs = config_attrs,
.var_names = plpks_var_names_static,
};
@@ -234,7 +206,6 @@ static const struct secvar_operations plpks_secvar_ops_dynamic = {
.set = plpks_set_variable,
.format = plpks_secvar_format,
.max_size = plpks_max_size,
- .config_attrs = config_attrs,
.var_names = plpks_var_names_dynamic,
};
diff --git a/arch/powerpc/platforms/pseries/plpks-sysfs.c b/arch/powerpc/platforms/pseries/plpks-sysfs.c
new file mode 100644
index 000000000000..01d526185783
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/plpks-sysfs.c
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
+ *
+ * This code exposes PLPKS config to user via sysfs
+ */
+
+#define pr_fmt(fmt) "plpks-sysfs: "fmt
+
+#include <linux/init.h>
+#include <linux/printk.h>
+#include <linux/types.h>
+#include <asm/machdep.h>
+#include <asm/plpks.h>
+
+/* config attributes for sysfs */
+#define PLPKS_CONFIG_ATTR(name, fmt, func) \
+ static ssize_t name##_show(struct kobject *kobj, \
+ struct kobj_attribute *attr, \
+ char *buf) \
+ { \
+ return sysfs_emit(buf, fmt, func()); \
+ } \
+ static struct kobj_attribute attr_##name = __ATTR_RO(name)
+
+PLPKS_CONFIG_ATTR(version, "%u\n", plpks_get_version);
+PLPKS_CONFIG_ATTR(max_object_size, "%u\n", plpks_get_maxobjectsize);
+PLPKS_CONFIG_ATTR(total_size, "%u\n", plpks_get_totalsize);
+PLPKS_CONFIG_ATTR(used_space, "%u\n", plpks_get_usedspace);
+PLPKS_CONFIG_ATTR(supported_policies, "%08x\n", plpks_get_supportedpolicies);
+PLPKS_CONFIG_ATTR(signed_update_algorithms, "%016llx\n",
+ plpks_get_signedupdatealgorithms);
+
+static const struct attribute *config_attrs[] = {
+ &attr_version.attr,
+ &attr_max_object_size.attr,
+ &attr_total_size.attr,
+ &attr_used_space.attr,
+ &attr_supported_policies.attr,
+ &attr_signed_update_algorithms.attr,
+ NULL,
+};
+
+static struct kobject *plpks_kobj, *plpks_config_kobj;
+
+int plpks_config_create_softlink(struct kobject *from)
+{
+ if (!plpks_config_kobj)
+ return -EINVAL;
+ return sysfs_create_link(from, plpks_config_kobj, "config");
+}
+
+static __init int plpks_sysfs_config(struct kobject *kobj)
+{
+ struct attribute_group config_group = {
+ .name = NULL,
+ .attrs = (struct attribute **)config_attrs,
+ };
+
+ return sysfs_create_group(kobj, &config_group);
+}
+
+static __init int plpks_sysfs_init(void)
+{
+ int rc;
+
+ if (!plpks_is_available())
+ return -ENODEV;
+
+ plpks_kobj = kobject_create_and_add("plpks", firmware_kobj);
+ if (!plpks_kobj) {
+ pr_err("Failed to create plpks kobj\n");
+ return -ENOMEM;
+ }
+
+ plpks_config_kobj = kobject_create_and_add("config", plpks_kobj);
+ if (!plpks_config_kobj) {
+ pr_err("Failed to create plpks config kobj\n");
+ kobject_put(plpks_kobj);
+ return -ENOMEM;
+ }
+
+ rc = plpks_sysfs_config(plpks_config_kobj);
+ if (rc) {
+ pr_err("Failed to create attribute group for plpks config\n");
+ kobject_put(plpks_config_kobj);
+ kobject_put(plpks_kobj);
+ return rc;
+ }
+
+ return 0;
+}
+
+machine_subsys_initcall(pseries, plpks_sysfs_init);
--
2.47.3
^ permalink raw reply related
* [PATCH v6 5/6] keys/trusted_keys: establish PKWM as a trusted source
From: Srish Srinivasan @ 2026-02-01 13:59 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module,
ssrish
In-Reply-To: <20260201135930.898721-1-ssrish@linux.ibm.com>
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>
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
---
MAINTAINERS | 9 +
include/keys/trusted-type.h | 7 +-
include/keys/trusted_pkwm.h | 33 ++++
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 | 190 ++++++++++++++++++++++
7 files changed, 253 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 0efa8cc6775b..b037648e66fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14013,6 +14013,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_pkwm.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..03527162613f 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;
+ void *private;
};
struct trusted_key_ops {
diff --git a/include/keys/trusted_pkwm.h b/include/keys/trusted_pkwm.h
new file mode 100644
index 000000000000..4035b9776394
--- /dev/null
+++ b/include/keys/trusted_pkwm.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PKWM_TRUSTED_KEY_H
+#define __PKWM_TRUSTED_KEY_H
+
+#include <keys/trusted-type.h>
+#include <linux/bitops.h>
+#include <linux/printk.h>
+
+extern struct trusted_key_ops pkwm_trusted_key_ops;
+
+struct trusted_pkwm_options {
+ u16 wrap_flags;
+};
+
+static inline void dump_options(struct trusted_key_options *o)
+{
+ const struct trusted_pkwm_options *pkwm;
+ bool sb_audit_or_enforce_bit;
+ bool sb_enforce_bit;
+
+ pkwm = o->private;
+ sb_audit_or_enforce_bit = pkwm->wrap_flags & BIT(0);
+ sb_enforce_bit = pkwm->wrap_flags & BIT(1);
+
+ if (sb_audit_or_enforce_bit)
+ pr_debug("secure boot mode required: audit or enforce");
+ else if (sb_enforce_bit)
+ pr_debug("secure boot mode required: enforce");
+ else
+ pr_debug("secure boot mode required: disabled");
+}
+
+#endif
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index 204a68c1429d..9e00482d886a 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -46,6 +46,14 @@ config TRUSTED_KEYS_DCP
help
Enable use of NXP's DCP (Data Co-Processor) as trusted key backend.
+config TRUSTED_KEYS_PKWM
+ bool "PKWM-based trusted keys"
+ depends on PSERIES_PLPKS >= TRUSTED_KEYS
+ default y
+ select HAVE_TRUSTED_KEYS
+ help
+ Enable use of IBM PowerVM Key Wrapping Module (PKWM) as a trusted key backend.
+
if !HAVE_TRUSTED_KEYS
comment "No trust source selected!"
endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index f0f3b27f688b..5fc053a21dad 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -16,3 +16,5 @@ trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
trusted-$(CONFIG_TRUSTED_KEYS_CAAM) += trusted_caam.o
trusted-$(CONFIG_TRUSTED_KEYS_DCP) += trusted_dcp.o
+
+trusted-$(CONFIG_TRUSTED_KEYS_PKWM) += trusted_pkwm.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index b1680ee53f86..2d328de170e8 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -12,6 +12,7 @@
#include <keys/trusted_caam.h>
#include <keys/trusted_dcp.h>
#include <keys/trusted_tpm.h>
+#include <keys/trusted_pkwm.h>
#include <linux/capability.h>
#include <linux/err.h>
#include <linux/init.h>
@@ -31,7 +32,7 @@ MODULE_PARM_DESC(rng, "Select trusted key RNG");
static char *trusted_key_source;
module_param_named(source, trusted_key_source, charp, 0);
-MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam or dcp)");
+MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam, dcp or pkwm)");
static const struct trusted_key_source trusted_key_sources[] = {
#if defined(CONFIG_TRUSTED_KEYS_TPM)
@@ -46,6 +47,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
#if defined(CONFIG_TRUSTED_KEYS_DCP)
{ "dcp", &dcp_trusted_key_ops },
#endif
+#if defined(CONFIG_TRUSTED_KEYS_PKWM)
+ { "pkwm", &pkwm_trusted_key_ops },
+#endif
};
DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal);
diff --git a/security/keys/trusted-keys/trusted_pkwm.c b/security/keys/trusted-keys/trusted_pkwm.c
new file mode 100644
index 000000000000..4f391b77a907
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_pkwm.c
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
+ */
+
+#include <keys/trusted_pkwm.h>
+#include <keys/trusted-type.h>
+#include <linux/build_bug.h>
+#include <linux/key-type.h>
+#include <linux/parser.h>
+#include <asm/plpks.h>
+
+enum {
+ Opt_err,
+ Opt_wrap_flags,
+};
+
+static const match_table_t key_tokens = {
+ {Opt_wrap_flags, "wrap_flags=%s"},
+ {Opt_err, NULL}
+};
+
+static int getoptions(char *datablob, struct trusted_key_options *opt)
+{
+ substring_t args[MAX_OPT_ARGS];
+ char *p = datablob;
+ int token;
+ int res;
+ u16 wrap_flags;
+ unsigned long token_mask = 0;
+ struct trusted_pkwm_options *pkwm;
+
+ if (!datablob)
+ return 0;
+
+ pkwm = opt->private;
+
+ while ((p = strsep(&datablob, " \t"))) {
+ if (*p == '\0' || *p == ' ' || *p == '\t')
+ continue;
+
+ token = match_token(p, key_tokens, args);
+ if (test_and_set_bit(token, &token_mask))
+ return -EINVAL;
+
+ switch (token) {
+ case Opt_wrap_flags:
+ res = kstrtou16(args[0].from, 16, &wrap_flags);
+ if (res < 0 || wrap_flags > 2)
+ return -EINVAL;
+ pkwm->wrap_flags = wrap_flags;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+ return 0;
+}
+
+static struct trusted_key_options *trusted_options_alloc(void)
+{
+ struct trusted_key_options *options;
+ struct trusted_pkwm_options *pkwm;
+
+ options = kzalloc(sizeof(*options), GFP_KERNEL);
+
+ if (options) {
+ pkwm = kzalloc(sizeof(*pkwm), GFP_KERNEL);
+
+ if (!pkwm) {
+ kfree_sensitive(options);
+ options = NULL;
+ } else {
+ options->private = pkwm;
+ }
+ }
+
+ return options;
+}
+
+static int trusted_pkwm_seal(struct trusted_key_payload *p, char *datablob)
+{
+ struct trusted_key_options *options = NULL;
+ struct trusted_pkwm_options *pkwm = NULL;
+ u8 *input_buf, *output_buf;
+ u32 output_len, input_len;
+ int rc;
+
+ options = trusted_options_alloc();
+
+ if (!options)
+ return -ENOMEM;
+
+ rc = getoptions(datablob, options);
+ if (rc < 0)
+ goto out;
+ dump_options(options);
+
+ input_len = p->key_len;
+ input_buf = kmalloc(ALIGN(input_len, 4096), GFP_KERNEL);
+ if (!input_buf) {
+ pr_err("Input buffer allocation failed. Returning -ENOMEM.");
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ memcpy(input_buf, p->key, p->key_len);
+
+ pkwm = options->private;
+
+ rc = plpks_wrap_object(&input_buf, input_len, pkwm->wrap_flags,
+ &output_buf, &output_len);
+ if (!rc) {
+ memcpy(p->blob, output_buf, output_len);
+ p->blob_len = output_len;
+ dump_payload(p);
+ } else {
+ pr_err("Wrapping of payload key failed: %d\n", rc);
+ }
+
+ kfree(input_buf);
+ kfree(output_buf);
+
+out:
+ kfree_sensitive(options->private);
+ kfree_sensitive(options);
+ return rc;
+}
+
+static int trusted_pkwm_unseal(struct trusted_key_payload *p, char *datablob)
+{
+ u8 *input_buf, *output_buf;
+ u32 input_len, output_len;
+ int rc;
+
+ input_len = p->blob_len;
+ input_buf = kmalloc(ALIGN(input_len, 4096), GFP_KERNEL);
+ if (!input_buf) {
+ pr_err("Input buffer allocation failed. Returning -ENOMEM.");
+ return -ENOMEM;
+ }
+
+ memcpy(input_buf, p->blob, p->blob_len);
+
+ rc = plpks_unwrap_object(&input_buf, input_len, &output_buf,
+ &output_len);
+ if (!rc) {
+ memcpy(p->key, output_buf, output_len);
+ p->key_len = output_len;
+ dump_payload(p);
+ } else {
+ pr_err("Unwrapping of payload failed: %d\n", rc);
+ }
+
+ kfree(input_buf);
+ kfree(output_buf);
+
+ return rc;
+}
+
+static int trusted_pkwm_init(void)
+{
+ int ret;
+
+ if (!plpks_wrapping_is_supported()) {
+ pr_err("H_PKS_WRAP_OBJECT interface not supported\n");
+ return -ENODEV;
+ }
+
+ ret = plpks_gen_wrapping_key();
+ if (ret) {
+ pr_err("Failed to generate default wrapping key\n");
+ return -EINVAL;
+ }
+
+ return register_key_type(&key_type_trusted);
+}
+
+static void trusted_pkwm_exit(void)
+{
+ unregister_key_type(&key_type_trusted);
+}
+
+struct trusted_key_ops pkwm_trusted_key_ops = {
+ .migratable = 0, /* non-migratable */
+ .init = trusted_pkwm_init,
+ .seal = trusted_pkwm_seal,
+ .unseal = trusted_pkwm_unseal,
+ .exit = trusted_pkwm_exit,
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v6 1/6] pseries/plpks: fix kernel-doc comment inconsistencies
From: Srish Srinivasan @ 2026-02-01 13:59 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module,
ssrish
In-Reply-To: <20260201135930.898721-1-ssrish@linux.ibm.com>
Fix issues with comments for all the applicable functions to be
consistent with kernel-doc format. Move them before the function
definition as opposed to the function prototype.
Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
---
arch/powerpc/include/asm/plpks.h | 77 ------
arch/powerpc/platforms/pseries/plpks.c | 328 ++++++++++++++++++++++++-
2 files changed, 318 insertions(+), 87 deletions(-)
diff --git a/arch/powerpc/include/asm/plpks.h b/arch/powerpc/include/asm/plpks.h
index 7a84069759b0..f303922bf622 100644
--- a/arch/powerpc/include/asm/plpks.h
+++ b/arch/powerpc/include/asm/plpks.h
@@ -67,122 +67,45 @@ struct plpks_var_name_list {
struct plpks_var_name varlist[];
};
-/**
- * Updates the authenticated variable. It expects NULL as the component.
- */
int plpks_signed_update_var(struct plpks_var *var, u64 flags);
-/**
- * Writes the specified var and its data to PKS.
- * Any caller of PKS driver should present a valid component type for
- * their variable.
- */
int plpks_write_var(struct plpks_var var);
-/**
- * Removes the specified var and its data from PKS.
- */
int plpks_remove_var(char *component, u8 varos,
struct plpks_var_name vname);
-/**
- * Returns the data for the specified os variable.
- *
- * Caller must allocate a buffer in var->data with length in var->datalen.
- * If no buffer is provided, var->datalen will be populated with the object's
- * size.
- */
int plpks_read_os_var(struct plpks_var *var);
-/**
- * Returns the data for the specified firmware variable.
- *
- * Caller must allocate a buffer in var->data with length in var->datalen.
- * If no buffer is provided, var->datalen will be populated with the object's
- * size.
- */
int plpks_read_fw_var(struct plpks_var *var);
-/**
- * Returns the data for the specified bootloader variable.
- *
- * Caller must allocate a buffer in var->data with length in var->datalen.
- * If no buffer is provided, var->datalen will be populated with the object's
- * size.
- */
int plpks_read_bootloader_var(struct plpks_var *var);
-/**
- * Returns if PKS is available on this LPAR.
- */
bool plpks_is_available(void);
-/**
- * Returns version of the Platform KeyStore.
- */
u8 plpks_get_version(void);
-/**
- * Returns hypervisor storage overhead per object, not including the size of
- * the object or label. Only valid for config version >= 2
- */
u16 plpks_get_objoverhead(void);
-/**
- * Returns maximum password size. Must be >= 32 bytes
- */
u16 plpks_get_maxpwsize(void);
-/**
- * Returns maximum object size supported by Platform KeyStore.
- */
u16 plpks_get_maxobjectsize(void);
-/**
- * Returns maximum object label size supported by Platform KeyStore.
- */
u16 plpks_get_maxobjectlabelsize(void);
-/**
- * Returns total size of the configured Platform KeyStore.
- */
u32 plpks_get_totalsize(void);
-/**
- * Returns used space from the total size of the Platform KeyStore.
- */
u32 plpks_get_usedspace(void);
-/**
- * Returns bitmask of policies supported by the hypervisor.
- */
u32 plpks_get_supportedpolicies(void);
-/**
- * Returns maximum byte size of a single object supported by the hypervisor.
- * Only valid for config version >= 3
- */
u32 plpks_get_maxlargeobjectsize(void);
-/**
- * Returns bitmask of signature algorithms supported for signed updates.
- * Only valid for config version >= 3
- */
u64 plpks_get_signedupdatealgorithms(void);
-/**
- * Returns the length of the PLPKS password in bytes.
- */
u16 plpks_get_passwordlen(void);
-/**
- * Called in early init to retrieve and clear the PLPKS password from the DT.
- */
void plpks_early_init_devtree(void);
-/**
- * Populates the FDT with the PLPKS password to prepare for kexec.
- */
int plpks_populate_fdt(void *fdt);
#else // CONFIG_PSERIES_PLPKS
static inline bool plpks_is_available(void) { return false; }
diff --git a/arch/powerpc/platforms/pseries/plpks.c b/arch/powerpc/platforms/pseries/plpks.c
index b1667ed05f98..03722fabf9c3 100644
--- a/arch/powerpc/platforms/pseries/plpks.c
+++ b/arch/powerpc/platforms/pseries/plpks.c
@@ -312,40 +312,107 @@ static int _plpks_get_config(void)
return rc;
}
+/**
+ * plpks_get_version() - Get the version of the PLPKS config structure.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads the PLPKS config structure version and saves it in a file local static
+ * version variable.
+ *
+ * Returns: On success the saved PLPKS config structure version is returned, 0
+ * if not.
+ */
u8 plpks_get_version(void)
{
return version;
}
+/**
+ * plpks_get_objoverhead() - Get the hypervisor storage overhead per object.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads the per object hypervisor storage overhead in bytes into the local
+ * static objoverhead variable, excluding the size of the object or the label.
+ * This value can be treated as valid only when the PLPKS config structure
+ * version >= 2.
+ *
+ * Returns: If PLPKS config structure version >= 2 then the storage overhead is
+ * returned, 0 otherwise.
+ */
u16 plpks_get_objoverhead(void)
{
return objoverhead;
}
+/**
+ * plpks_get_maxpwsize() - Get the maximum password size.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads the maximum password size and checks if it is 32 bytes at the least
+ * before storing it in the local static maxpwsize variable.
+ *
+ * Returns: On success the maximum password size is returned, 0 if not.
+ */
u16 plpks_get_maxpwsize(void)
{
return maxpwsize;
}
+/**
+ * plpks_get_maxobjectsize() - Get the maximum object size supported by the
+ * PLPKS.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads the maximum object size into the file local static maxobjsize variable.
+ *
+ * Returns: On success the maximum object size is returned, 0 if not.
+ */
u16 plpks_get_maxobjectsize(void)
{
return maxobjsize;
}
+/**
+ * plpks_get_maxobjectlabelsize() - Get the maximum object label size supported
+ * by the PLPKS.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads the maximum object label size into the local static maxobjlabelsize
+ * variable.
+ *
+ * Returns: On success the maximum object label size is returned, 0 if not.
+ */
u16 plpks_get_maxobjectlabelsize(void)
{
return maxobjlabelsize;
}
+/**
+ * plpks_get_totalsize() - Get the total size of the PLPKS that is configured.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads the total size of the PLPKS that is configured for the LPAR into the
+ * file local static totalsize variable.
+ *
+ * Returns: On success the total size of the PLPKS configured is returned, 0 if
+ * not.
+ */
u32 plpks_get_totalsize(void)
{
return totalsize;
}
+/**
+ * plpks_get_usedspace() - Get the used space from the total size of the PLPKS.
+ *
+ * Invoke the H_PKS_GET_CONFIG HCALL to refresh the latest value for the used
+ * space as this keeps changing with the creation and removal of objects in the
+ * PLPKS.
+ *
+ * Returns: On success the used space is returned, 0 if not.
+ */
u32 plpks_get_usedspace(void)
{
- // Unlike other config values, usedspace regularly changes as objects
- // are updated, so we need to refresh.
int rc = _plpks_get_config();
if (rc) {
pr_err("Couldn't get config, rc: %d\n", rc);
@@ -354,26 +421,84 @@ u32 plpks_get_usedspace(void)
return usedspace;
}
+/**
+ * plpks_get_supportedpolicies() - Get a bitmask of the policies supported by
+ * the hypervisor.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads a bitmask of the policies supported by the hypervisor into the file
+ * local static supportedpolicies variable.
+ *
+ * Returns: On success the bitmask of the policies supported by the hypervisor
+ * are returned, 0 if not.
+ */
u32 plpks_get_supportedpolicies(void)
{
return supportedpolicies;
}
+/**
+ * plpks_get_maxlargeobjectsize() - Get the maximum object size supported for
+ * PLPKS config structure version >= 3
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads the maximum object size into the local static maxlargeobjectsize
+ * variable for PLPKS config structure version >= 3. This was introduced
+ * starting with PLPKS config structure version 3 to allow for objects of
+ * size >= 64K.
+ *
+ * Returns: If PLPKS config structure version >= 3 then the new maximum object
+ * size is returned, 0 if not.
+ */
u32 plpks_get_maxlargeobjectsize(void)
{
return maxlargeobjectsize;
}
+/**
+ * plpks_get_signedupdatealgorithms() - Get a bitmask of the signature
+ * algorithms supported for signed updates.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads a bitmask of the signature algorithms supported for signed updates into
+ * the file local static signedupdatealgorithms variable. This is valid only
+ * when the PLPKS config structure version >= 3.
+ *
+ * Returns: On success the bitmask of the signature algorithms supported for
+ * signed updates is returned, 0 if not.
+ */
u64 plpks_get_signedupdatealgorithms(void)
{
return signedupdatealgorithms;
}
+/**
+ * plpks_get_passwordlen() - Get the length of the PLPKS password in bytes.
+ *
+ * The H_PKS_GEN_PASSWORD HCALL makes the hypervisor generate a random password
+ * for the specified consumer, apply that password to the PLPKS and return it to
+ * the caller. In this process, the password length for the OS consumer is
+ * stored in the local static ospasswordlength variable.
+ *
+ * Returns: On success the password length for the OS consumer in bytes is
+ * returned, 0 if not.
+ */
u16 plpks_get_passwordlen(void)
{
return ospasswordlength;
}
+/**
+ * plpks_is_available() - Get the PLPKS availability status for the LPAR.
+ *
+ * The availability of PLPKS is inferred based upon the successful execution of
+ * the H_PKS_GET_CONFIG HCALL provided the firmware supports this feature. The
+ * H_PKS_GET_CONFIG HCALL reads the configuration and status information related
+ * to the PLPKS. The configuration structure provides a version number to inform
+ * the caller of the supported features.
+ *
+ * Returns: true is returned if PLPKS is available, false if not.
+ */
bool plpks_is_available(void)
{
int rc;
@@ -425,6 +550,35 @@ static int plpks_confirm_object_flushed(struct label *label,
return pseries_status_to_err(rc);
}
+/**
+ * plpks_signed_update_var() - Update the specified authenticated variable.
+ * @var: authenticated variable to be updated
+ * @flags: signed update request operation flags
+ *
+ * The H_PKS_SIGNED_UPDATE HCALL performs a signed update to an object in the
+ * PLPKS. The object must have the signed update policy flag set.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if PLPKS modification is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid object label parameter
+ * if invalid object label len parameter
+ * if invalid or unsupported policy declaration
+ * if invalid signed update flags
+ * if invalid input data parameter
+ * if invalid input data len parameter
+ * if invalid continue token parameter
+ * -EPERM if access is denied
+ * -ENOMEM if there is inadequate memory to perform the operation
+ * -EBUSY if unable to handle the request or long running operation
+ * initiated, retry later
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
int plpks_signed_update_var(struct plpks_var *var, u64 flags)
{
unsigned long retbuf[PLPAR_HCALL9_BUFSIZE] = {0};
@@ -481,6 +635,33 @@ int plpks_signed_update_var(struct plpks_var *var, u64 flags)
return rc;
}
+/**
+ * plpks_write_var() - Write the specified variable and its data to PLPKS.
+ * @var: variable to be written into the PLPKS
+ *
+ * The H_PKS_WRITE_OBJECT HCALL writes an object into the PLPKS. The caller must
+ * provide a valid component type for the variable, and the signed update policy
+ * flag must not be set.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if PLPKS modification is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid object label parameter
+ * if invalid object label len parameter
+ * if invalid or unsupported policy declaration
+ * if invalid input data parameter
+ * if invalid input data len parameter
+ * -EPERM if access is denied
+ * -ENOMEM if unable to store the requested object in the space available
+ * -EBUSY if unable to handle the request
+ * -EEXIST if the object label already exists
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
int plpks_write_var(struct plpks_var var)
{
unsigned long retbuf[PLPAR_HCALL_BUFSIZE] = { 0 };
@@ -520,6 +701,30 @@ int plpks_write_var(struct plpks_var var)
return rc;
}
+/**
+ * plpks_remove_var() - Remove the specified variable and its data from PLPKS.
+ * @component: metadata prefix in the object label metadata structure
+ * @varos: metadata OS flags in the object label metadata structure
+ * @vname: object label for the object that needs to be removed
+ *
+ * The H_PKS_REMOVE_OBJECT HCALL removes an object from the PLPKS. The removal
+ * is independent of the policy bits that are set.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if PLPKS modification is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid object label parameter
+ * if invalid object label len parameter
+ * -EPERM if access is denied
+ * -ENOENT if the requested object was not found
+ * -EBUSY if unable to handle the request
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
int plpks_remove_var(char *component, u8 varos, struct plpks_var_name vname)
{
unsigned long retbuf[PLPAR_HCALL_BUFSIZE] = { 0 };
@@ -619,21 +824,119 @@ static int plpks_read_var(u8 consumer, struct plpks_var *var)
return rc;
}
+/**
+ * plpks_read_os_var() - Fetch the data for the specified variable that is
+ * owned by the OS consumer.
+ * @var: variable to be read from the PLPKS
+ *
+ * The consumer or the owner of the object is the os kernel. The
+ * H_PKS_READ_OBJECT HCALL reads an object from the PLPKS. The caller must
+ * allocate the buffer var->data and specify the length for this buffer in
+ * var->datalen. If no buffer is provided, var->datalen will be populated with
+ * the requested object's size.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid object label parameter
+ * if invalid object label len parameter
+ * if invalid output data parameter
+ * if invalid output data len parameter
+ * -EPERM if access is denied
+ * -ENOENT if the requested object was not found
+ * -EFBIG if the requested object couldn't be
+ * stored in the buffer provided
+ * -EBUSY if unable to handle the request
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
int plpks_read_os_var(struct plpks_var *var)
{
return plpks_read_var(PLPKS_OS_OWNER, var);
}
+/**
+ * plpks_read_fw_var() - Fetch the data for the specified variable that is
+ * owned by the firmware consumer.
+ * @var: variable to be read from the PLPKS
+ *
+ * The consumer or the owner of the object is the firmware. The
+ * H_PKS_READ_OBJECT HCALL reads an object from the PLPKS. The caller must
+ * allocate the buffer var->data and specify the length for this buffer in
+ * var->datalen. If no buffer is provided, var->datalen will be populated with
+ * the requested object's size.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid object label parameter
+ * if invalid object label len parameter
+ * if invalid output data parameter
+ * if invalid output data len parameter
+ * -EPERM if access is denied
+ * -ENOENT if the requested object was not found
+ * -EFBIG if the requested object couldn't be
+ * stored in the buffer provided
+ * -EBUSY if unable to handle the request
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
int plpks_read_fw_var(struct plpks_var *var)
{
return plpks_read_var(PLPKS_FW_OWNER, var);
}
+/**
+ * plpks_read_bootloader_var() - Fetch the data for the specified variable
+ * owned by the bootloader consumer.
+ * @var: variable to be read from the PLPKS
+ *
+ * The consumer or the owner of the object is the bootloader. The
+ * H_PKS_READ_OBJECT HCALL reads an object from the PLPKS. The caller must
+ * allocate the buffer var->data and specify the length for this buffer in
+ * var->datalen. If no buffer is provided, var->datalen will be populated with
+ * the requested object's size.
+ *
+ * Possible reasons for the returned errno values:
+ *
+ * -ENXIO if PLPKS is not supported
+ * -EIO if PLPKS access is blocked due to the LPAR's state
+ * if an error occurred while processing the request
+ * -EINVAL if invalid authorization parameter
+ * if invalid object label parameter
+ * if invalid object label len parameter
+ * if invalid output data parameter
+ * if invalid output data len parameter
+ * -EPERM if access is denied
+ * -ENOENT if the requested object was not found
+ * -EFBIG if the requested object couldn't be
+ * stored in the buffer provided
+ * -EBUSY if unable to handle the request
+ *
+ * Returns: On success 0 is returned, a negative errno if not.
+ */
int plpks_read_bootloader_var(struct plpks_var *var)
{
return plpks_read_var(PLPKS_BOOTLOADER_OWNER, var);
}
+/**
+ * plpks_populate_fdt(): Populates the FDT with the PLPKS password to prepare
+ * for kexec.
+ * @fdt: pointer to the device tree blob
+ *
+ * Upon confirming the existence of the chosen node, invoke fdt_setprop to
+ * populate the device tree with the PLPKS password in order to prepare for
+ * kexec.
+ *
+ * Returns: On success 0 is returned, a negative value if not.
+ */
int plpks_populate_fdt(void *fdt)
{
int chosen_offset = fdt_path_offset(fdt, "/chosen");
@@ -647,14 +950,19 @@ int plpks_populate_fdt(void *fdt)
return fdt_setprop(fdt, chosen_offset, "ibm,plpks-pw", ospassword, ospasswordlength);
}
-// Once a password is registered with the hypervisor it cannot be cleared without
-// rebooting the LPAR, so to keep using the PLPKS across kexec boots we need to
-// recover the previous password from the FDT.
-//
-// There are a few challenges here. We don't want the password to be visible to
-// users, so we need to clear it from the FDT. This has to be done in early boot.
-// Clearing it from the FDT would make the FDT's checksum invalid, so we have to
-// manually cause the checksum to be recalculated.
+/**
+ * plpks_early_init_devtree() - Retrieves and clears the PLPKS password from the
+ * DT in early init.
+ *
+ * Once a password is registered with the hypervisor it cannot be cleared
+ * without rebooting the LPAR, so to keep using the PLPKS across kexec boots we
+ * need to recover the previous password from the FDT.
+ *
+ * There are a few challenges here. We don't want the password to be visible to
+ * users, so we need to clear it from the FDT. This has to be done in early
+ * boot. Clearing it from the FDT would make the FDT's checksum invalid, so we
+ * have to manually cause the checksum to be recalculated.
+ */
void __init plpks_early_init_devtree(void)
{
void *fdt = initial_boot_params;
--
2.47.3
^ permalink raw reply related
* [PATCH v6 3/6] pseries/plpks: expose PowerVM wrapping features via the sysfs
From: Srish Srinivasan @ 2026-02-01 13:59 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module,
ssrish
In-Reply-To: <20260201135930.898721-1-ssrish@linux.ibm.com>
Starting with Power11, PowerVM supports a new feature called "Key Wrapping"
that protects user secrets by wrapping them using a hypervisor generated
wrapping key. The status of this feature can be read by the
H_PKS_GET_CONFIG HCALL.
Expose the Power LPAR Platform KeyStore (PLPKS) wrapping features config
via the sysfs file /sys/firmware/plpks/config/wrapping_features.
Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
---
.../ABI/testing/sysfs-firmware-plpks | 8 ++++++++
arch/powerpc/include/asm/hvcall.h | 4 +++-
arch/powerpc/include/asm/plpks.h | 3 +++
arch/powerpc/platforms/pseries/plpks-sysfs.c | 2 ++
arch/powerpc/platforms/pseries/plpks.c | 20 +++++++++++++++++++
5 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-firmware-plpks b/Documentation/ABI/testing/sysfs-firmware-plpks
index af0353f34115..cba061e4eee2 100644
--- a/Documentation/ABI/testing/sysfs-firmware-plpks
+++ b/Documentation/ABI/testing/sysfs-firmware-plpks
@@ -48,3 +48,11 @@ Description: Bitmask of flags indicating which algorithms the hypervisor
supports for signed update of objects, represented as a 16 byte
hexadecimal ASCII string. Consult the hypervisor documentation
for what these flags mean.
+
+What: /sys/firmware/plpks/config/wrapping_features
+Date: November 2025
+Contact: Srish Srinivasan <ssrish@linux.ibm.com>
+Description: Bitmask of the wrapping features indicating the wrapping
+ algorithms that are supported for the H_PKS_WRAP_OBJECT requests
+ , represented as a 8 byte hexadecimal ASCII string. Consult the
+ hypervisor documentation for what these flags mean.
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index 9aef16149d92..dff90a7d7f70 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -360,7 +360,9 @@
#define H_GUEST_RUN_VCPU 0x480
#define H_GUEST_COPY_MEMORY 0x484
#define H_GUEST_DELETE 0x488
-#define MAX_HCALL_OPCODE H_GUEST_DELETE
+#define H_PKS_WRAP_OBJECT 0x490
+#define H_PKS_UNWRAP_OBJECT 0x494
+#define MAX_HCALL_OPCODE H_PKS_UNWRAP_OBJECT
/* Scope args for H_SCM_UNBIND_ALL */
#define H_UNBIND_SCOPE_ALL (0x1)
diff --git a/arch/powerpc/include/asm/plpks.h b/arch/powerpc/include/asm/plpks.h
index 8829a13bfda0..8f034588fdf7 100644
--- a/arch/powerpc/include/asm/plpks.h
+++ b/arch/powerpc/include/asm/plpks.h
@@ -23,6 +23,7 @@
#define PLPKS_IMMUTABLE PPC_BIT32(5) // Once written, object cannot be removed
#define PLPKS_TRANSIENT PPC_BIT32(6) // Object does not persist through reboot
#define PLPKS_SIGNEDUPDATE PPC_BIT32(7) // Object can only be modified by signed updates
+#define PLPKS_WRAPPINGKEY PPC_BIT32(8) // Object contains a wrapping key
#define PLPKS_HVPROVISIONED PPC_BIT32(28) // Hypervisor has provisioned this object
// Signature algorithm flags from signed_update_algorithms
@@ -103,6 +104,8 @@ u32 plpks_get_maxlargeobjectsize(void);
u64 plpks_get_signedupdatealgorithms(void);
+u64 plpks_get_wrappingfeatures(void);
+
u16 plpks_get_passwordlen(void);
void plpks_early_init_devtree(void);
diff --git a/arch/powerpc/platforms/pseries/plpks-sysfs.c b/arch/powerpc/platforms/pseries/plpks-sysfs.c
index 01d526185783..c2ebcbb41ae3 100644
--- a/arch/powerpc/platforms/pseries/plpks-sysfs.c
+++ b/arch/powerpc/platforms/pseries/plpks-sysfs.c
@@ -30,6 +30,7 @@ PLPKS_CONFIG_ATTR(used_space, "%u\n", plpks_get_usedspace);
PLPKS_CONFIG_ATTR(supported_policies, "%08x\n", plpks_get_supportedpolicies);
PLPKS_CONFIG_ATTR(signed_update_algorithms, "%016llx\n",
plpks_get_signedupdatealgorithms);
+PLPKS_CONFIG_ATTR(wrapping_features, "%016llx\n", plpks_get_wrappingfeatures);
static const struct attribute *config_attrs[] = {
&attr_version.attr,
@@ -38,6 +39,7 @@ static const struct attribute *config_attrs[] = {
&attr_used_space.attr,
&attr_supported_policies.attr,
&attr_signed_update_algorithms.attr,
+ &attr_wrapping_features.attr,
NULL,
};
diff --git a/arch/powerpc/platforms/pseries/plpks.c b/arch/powerpc/platforms/pseries/plpks.c
index 03722fabf9c3..4a08f51537c8 100644
--- a/arch/powerpc/platforms/pseries/plpks.c
+++ b/arch/powerpc/platforms/pseries/plpks.c
@@ -38,6 +38,7 @@ static u32 usedspace;
static u32 supportedpolicies;
static u32 maxlargeobjectsize;
static u64 signedupdatealgorithms;
+static u64 wrappingfeatures;
struct plpks_auth {
u8 version;
@@ -248,6 +249,7 @@ static int _plpks_get_config(void)
__be32 supportedpolicies;
__be32 maxlargeobjectsize;
__be64 signedupdatealgorithms;
+ __be64 wrappingfeatures;
u8 rsvd1[476];
} __packed * config;
size_t size;
@@ -280,6 +282,7 @@ static int _plpks_get_config(void)
supportedpolicies = be32_to_cpu(config->supportedpolicies);
maxlargeobjectsize = be32_to_cpu(config->maxlargeobjectsize);
signedupdatealgorithms = be64_to_cpu(config->signedupdatealgorithms);
+ wrappingfeatures = be64_to_cpu(config->wrappingfeatures);
// Validate that the numbers we get back match the requirements of the spec
if (maxpwsize < 32) {
@@ -472,6 +475,23 @@ u64 plpks_get_signedupdatealgorithms(void)
return signedupdatealgorithms;
}
+/**
+ * plpks_get_wrappingfeatures() - Returns a bitmask of the wrapping features
+ * supported by the hypervisor.
+ *
+ * Successful execution of the H_PKS_GET_CONFIG HCALL during initialization
+ * reads a bitmask of the wrapping features supported by the hypervisor into the
+ * file local static wrappingfeatures variable. This is valid only when the
+ * PLPKS config structure version >= 3.
+ *
+ * Return:
+ * bitmask of the wrapping features supported by the hypervisor
+ */
+u64 plpks_get_wrappingfeatures(void)
+{
+ return wrappingfeatures;
+}
+
/**
* plpks_get_passwordlen() - Get the length of the PLPKS password in bytes.
*
--
2.47.3
^ permalink raw reply related
* [PATCH v6 0/6] Extend "trusted" keys to support a new trust source named the PowerVM Key Wrapping Module (PKWM)
From: Srish Srinivasan @ 2026-02-01 13:59 UTC (permalink / raw)
To: linux-integrity, keyrings, linuxppc-dev
Cc: maddy, mpe, npiggin, christophe.leroy, James.Bottomley, jarkko,
zohar, nayna, rnsastry, linux-kernel, linux-security-module,
ssrish
Power11 has introduced a feature called the PowerVM Key Wrapping Module
(PKWM), where PowerVM in combination with Power LPAR Platform KeyStore
(PLPKS) [1] supports a new feature called "Key Wrapping" [2] to protect
user secrets by wrapping them using a hypervisor generated wrapping key.
This wrapping key is an AES-GCM-256 symmetric key that is stored as an
object in the PLPKS. It has policy based protections that prevents it from
being read out or exposed to the user. This wrapping key can then be used
by the OS to wrap or unwrap secrets via hypervisor calls.
This patchset intends to add the PKWM, which is a combination of IBM
PowerVM and PLPKS, as a new trust source for trusted keys. The wrapping key
does not exist by default and its generation is requested by the kernel at
the time of PKWM initialization. This key is then persisted by the PKWM and
is used for wrapping any kernel provided key, and is never exposed to the
user. The kernel is aware of only the label to this wrapping key.
Along with the PKWM implementation, this patchset includes two preparatory
patches: one fixing the kernel-doc inconsistencies in the PLPKS code and
another reorganizing PLPKS config variables in the sysfs.
Changelog:
v6:
* Patch 1 to Patch 3:
- Add Nayna's Tested-by tag
* Patch 4
- Fix build error reported by kernel test robot <lkp@intel.com>
- Add Nayna's Tested-by tag
* Patch 5
- Add Nayna's Tested-by tag
v5:
* Patch 1 to Patch 3:
- Add Nayna's Reviewed-by tag
* Patch 4:
- Fix build error identified by chleroy@kernel.org
- Add Nayna's Reviewed-by tag
* Patch 5:
- Add Reviewed-by tags from Nayna and Jarkko
v4:
* Patch 5:
- Add a per-backend private data pointer in trusted_key_options
to store a pointer to the backend-specific options structure
- Minor clean-up
v3:
* Patch 2:
- Add Mimi's Reviewed-by tag
* Patch 4:
- Minor tweaks to some print statements
- Fix typos
* Patch 5:
- Fix typos
- Add Mimi's Reviewed-by tag
* Patch 6:
- Add Mimi's Reviewed-by tag
v2:
* Patch 2:
- Fix build warning detected by the kernel test bot
* Patch 5:
- Use pr_debug inside dump_options
- Replace policyhande with wrap_flags inside dump_options
- Provide meaningful error messages with error codes
Nayna Jain (1):
docs: trusted-encryped: add PKWM as a new trust source
Srish Srinivasan (5):
pseries/plpks: fix kernel-doc comment inconsistencies
powerpc/pseries: move the PLPKS config inside its own sysfs directory
pseries/plpks: expose PowerVM wrapping features via the sysfs
pseries/plpks: add HCALLs for PowerVM Key Wrapping Module
keys/trusted_keys: establish PKWM as a trusted source
.../ABI/testing/sysfs-firmware-plpks | 58 ++
Documentation/ABI/testing/sysfs-secvar | 65 --
.../admin-guide/kernel-parameters.txt | 1 +
Documentation/arch/powerpc/papr_hcalls.rst | 43 ++
.../security/keys/trusted-encrypted.rst | 50 ++
MAINTAINERS | 9 +
arch/powerpc/include/asm/hvcall.h | 4 +-
arch/powerpc/include/asm/plpks.h | 95 +--
arch/powerpc/include/asm/secvar.h | 1 -
arch/powerpc/kernel/secvar-sysfs.c | 21 +-
arch/powerpc/platforms/pseries/Makefile | 2 +-
arch/powerpc/platforms/pseries/plpks-secvar.c | 29 -
arch/powerpc/platforms/pseries/plpks-sysfs.c | 96 +++
arch/powerpc/platforms/pseries/plpks.c | 688 +++++++++++++++++-
include/keys/trusted-type.h | 7 +-
include/keys/trusted_pkwm.h | 33 +
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 | 190 +++++
20 files changed, 1207 insertions(+), 201 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-plpks
create mode 100644 arch/powerpc/platforms/pseries/plpks-sysfs.c
create mode 100644 include/keys/trusted_pkwm.h
create mode 100644 security/keys/trusted-keys/trusted_pkwm.c
--
2.47.3
^ permalink raw reply
* Re: [PATCH RESEND] apparmor: Replace deprecated strcpy with memcpy in gen_symlink_name
From: Thorsten Blum @ 2026-02-01 12:42 UTC (permalink / raw)
To: John Johansen
Cc: Paul Moore, James Morris, Serge E. Hallyn, apparmor,
linux-security-module, linux-kernel
In-Reply-To: <D73FFEAA-F246-4777-8CA8-32807F378423@linux.dev>
Hi John,
On 27. Nov 2025, at 11:18, Thorsten Blum wrote:
> On 27. Nov 2025, at 02:32, John Johansen wrote:
>> hey Thorsten,
>>
>> sorry I have actually pulled these in, and tested them. I didn't send out
>> the acks yet because I have another patch that I was waiting on a proper
>> signed-off-by: on.
>>
>> I am going to have to pull that one so I can push. I'll add acks now but
>> the push isn't going to happen for a few hours.
>>
>> Acked-by: John Johansen <john.johansen@canonical.com>
>
> Ah sorry for resending then, didn't know you looked at them already.
Did you ever push the commits? I can't find them anywhere.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH v2 3/3] landlock: transpose the layer masks data structure
From: Günther Noack @ 2026-02-01 12:24 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Randy Dunlap
In-Reply-To: <20260129.oozohZah1Uth@digikod.net>
On Thu, Jan 29, 2026 at 09:28:08PM +0100, Mickaël Salaün wrote:
> On Sun, Jan 25, 2026 at 08:58:53PM +0100, Günther Noack wrote:
> > At the moment, for the filesystem access rights, the data structure
> > has the same size as before, but once we introduce the 17th filesystem
> > access right, it will double in size (from 32 to 64 bytes), as
> > access_mask_t grows from 16 to 32 bit. See the link below for
> > measurements.
> >
> > Link: https://lore.kernel.org/all/20260120.haeCh4li9Vae@digikod.net/
>
> When adding extra links, please add a [1] reference at the end and use
> this reference in the commit message.
Ack, done.
–Günther
^ permalink raw reply
* Re: [PATCH v3 1/3] landlock: add backwards compatibility for restrict flags
From: Günther Noack @ 2026-02-01 12:24 UTC (permalink / raw)
To: Samasth Norway Ananda; +Cc: gnoack, mic, linux-security-module, linux-kernel
In-Reply-To: <20260128031814.2945394-2-samasth.norway.ananda@oracle.com>
On Tue, Jan 27, 2026 at 07:18:10PM -0800, Samasth Norway Ananda wrote:
> Add backwards compatibility handling for the restrict flags introduced
> in ABI version 7. This is shown as a separate code block (similar to
> the ruleset_attr handling in the switch statement) because restrict flags
> are passed to landlock_restrict_self() rather than being part of the
> ruleset attributes.
>
> Also fix misleading description of the /usr rule which incorrectly
> stated it "only allow[s] reading" when the code actually allows both
> reading and executing (LANDLOCK_ACCESS_FS_EXECUTE is included in
> allowed_access).
>
> Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
> ---
> Documentation/userspace-api/landlock.rst | 30 +++++++++++++++++-------
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst
> index 1ed25af0499f..c8ef1392a0c7 100644
> --- a/Documentation/userspace-api/landlock.rst
> +++ b/Documentation/userspace-api/landlock.rst
> @@ -157,11 +157,11 @@ This enables the creation of an inclusive ruleset that will contain our rules.
> }
>
> We can now add a new rule to this ruleset thanks to the returned file
> -descriptor referring to this ruleset. The rule will only allow reading the
> -file hierarchy ``/usr``. Without another rule, write actions would then be
> -denied by the ruleset. To add ``/usr`` to the ruleset, we open it with the
> -``O_PATH`` flag and fill the &struct landlock_path_beneath_attr with this file
> -descriptor.
> +descriptor referring to this ruleset. The rule will allow reading and
> +executing the file hierarchy ``/usr``. Without another rule, write actions
> +would then be denied by the ruleset. To add ``/usr`` to the ruleset, we open
> +it with the ``O_PATH`` flag and fill the &struct landlock_path_beneath_attr with
> +this file descriptor.
>
> .. code-block:: c
>
> @@ -233,10 +233,24 @@ to effectively block sending UDP datagrams to arbitrary ports.
> err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NET_PORT,
> &net_port, 0);
>
> +When passing a non-zero ``flags`` argument to ``landlock_restrict_self()``, a
> +similar backwards compatibility check is needed for the restrict flags
> +(see sys_landlock_restrict_self() documentation for available flags):
> +
> +.. code-block:: c
> +
> + __u32 restrict_flags = LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON;
> + if (abi < 7) {
> + /* Clear logging flags unsupported before ABI 7. */
> + restrict_flags &= ~(LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF |
> + LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
> + LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF);
> + }
> +
> The next step is to restrict the current thread from gaining more privileges
> (e.g. through a SUID binary). We now have a ruleset with the first rule
> -allowing read access to ``/usr`` while denying all other handled accesses for
> -the filesystem, and two more rules allowing DNS queries.
> +allowing read and execute access to ``/usr`` while denying all other handled
> +accesses for the filesystem, and two more rules allowing DNS queries.
>
> .. code-block:: c
>
> @@ -250,7 +264,7 @@ The current thread is now ready to sandbox itself with the ruleset.
>
> .. code-block:: c
>
> - if (landlock_restrict_self(ruleset_fd, 0)) {
> + if (landlock_restrict_self(ruleset_fd, restrict_flags)) {
> perror("Failed to enforce ruleset");
> close(ruleset_fd);
> return 1;
> --
> 2.50.1
>
Reviewed-by: Günther Noack <gnoack3000@gmail.com>
Thanks!
–Günther
^ permalink raw reply
* Re: [PATCH v3 2/3] landlock: add errata documentation section
From: Günther Noack @ 2026-02-01 12:23 UTC (permalink / raw)
To: Samasth Norway Ananda; +Cc: gnoack, mic, linux-security-module, linux-kernel
In-Reply-To: <20260128031814.2945394-3-samasth.norway.ananda@oracle.com>
On Tue, Jan 27, 2026 at 07:18:11PM -0800, Samasth Norway Ananda wrote:
> Add errata section with code examples for querying errata and a warning
> that most applications should not check errata. Use kernel-doc directives
> to include errata descriptions from the header files instead of manual
> links.
>
> Also enhance existing DOC sections in security/landlock/errata/abi-*.h
> files with Impact sections, and update the code comment in syscalls.c
> to remind developers to update errata documentation when applicable.
>
> This addresses the gap where the kernel implements errata tracking
> but provides no user-facing documentation on how to use it, while
> improving the existing technical documentation in-place rather than
> duplicating it.
>
> Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
> ---
> Documentation/userspace-api/landlock.rst | 67 ++++++++++++++++++++++--
> security/landlock/errata/abi-1.h | 8 +++
> security/landlock/errata/abi-4.h | 7 +++
> security/landlock/errata/abi-6.h | 10 ++++
> security/landlock/syscalls.c | 4 +-
> 5 files changed, 91 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst
> index c8ef1392a0c7..405b2d73e699 100644
> --- a/Documentation/userspace-api/landlock.rst
> +++ b/Documentation/userspace-api/landlock.rst
> @@ -8,7 +8,7 @@ Landlock: unprivileged access control
> =====================================
>
> :Author: Mickaël Salaün
> -:Date: December 2025
> +:Date: January 2026
>
> The goal of Landlock is to enable restriction of ambient rights (e.g. global
> filesystem or network access) for a set of processes. Because Landlock
> @@ -492,9 +492,68 @@ system call:
> printf("Landlock supports LANDLOCK_ACCESS_FS_REFER.\n");
> }
>
> -The following kernel interfaces are implicitly supported by the first ABI
> -version. Features only supported from a specific version are explicitly marked
> -as such.
> +All Landlock kernel interfaces are supported by the first ABI version unless
> +explicitly noted in their documentation.
> +
> +Landlock errata
> +---------------
> +
> +In addition to ABI versions, Landlock provides an errata mechanism to track
> +fixes for issues that may affect backwards compatibility or require userspace
> +awareness. The errata bitmask can be queried using:
> +
> +.. code-block:: c
> +
> + int errata;
> +
> + errata = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_ERRATA);
> + if (errata < 0) {
> + /* Landlock not available or disabled */
> + return 0;
> + }
> +
> +The returned value is a bitmask where each bit represents a specific erratum.
> +If bit N is set (``errata & (1 << (N - 1))``), then erratum N has been fixed
> +in the running kernel.
> +
> +.. warning::
> +
> + **Most applications should NOT check errata.** In 99.9% of cases, checking
> + errata is unnecessary, increases code complexity, and can potentially
> + decrease protection if misused. For example, disabling the sandbox when an
> + erratum is not fixed could leave the system less secure than using
> + Landlock's best-effort protection. When in doubt, ignore errata.
> +
> +.. kernel-doc:: security/landlock/errata/abi-4.h
> + :doc: erratum_1
> +
> +.. kernel-doc:: security/landlock/errata/abi-6.h
> + :doc: erratum_2
> +
> +.. kernel-doc:: security/landlock/errata/abi-1.h
> + :doc: erratum_3
> +
> +How to check for errata
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +If you determine that your application needs to check for specific errata,
> +use this pattern:
> +
> +.. code-block:: c
> +
> + int errata = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_ERRATA);
> + if (errata >= 0) {
> + /* Check for specific erratum (1-indexed) */
> + if (errata & (1 << (erratum_number - 1))) {
> + /* Erratum N is fixed in this kernel */
> + } else {
> + /* Erratum N is NOT fixed - consider implications for your use case */
> + }
> + }
> +
> +**Important:** Only check errata if your application specifically relies on
> +behavior that changed due to the fix. The fixes generally make Landlock less
> +restrictive or more correct, not more restrictive.
>
> Kernel interface
> ================
> diff --git a/security/landlock/errata/abi-1.h b/security/landlock/errata/abi-1.h
> index e8a2bff2e5b6..3f099555f059 100644
> --- a/security/landlock/errata/abi-1.h
> +++ b/security/landlock/errata/abi-1.h
> @@ -12,5 +12,13 @@
> * hierarchy down to its filesystem root and those from the related mount point
> * hierarchy. This prevents access right widening through rename or link
> * actions.
> + *
> + * Impact:
> + *
> + * Without this fix, it was possible to widen access rights through rename or
> + * link actions involving disconnected directories, potentially bypassing
> + * ``LANDLOCK_ACCESS_FS_REFER`` restrictions. This could allow privilege
> + * escalation in complex mount scenarios where directories become disconnected
> + * from their original mount points.
> */
> LANDLOCK_ERRATUM(3)
> diff --git a/security/landlock/errata/abi-4.h b/security/landlock/errata/abi-4.h
> index c052ee54f89f..fe11ec7d7ddf 100644
> --- a/security/landlock/errata/abi-4.h
> +++ b/security/landlock/errata/abi-4.h
> @@ -11,5 +11,12 @@
> * :manpage:`bind(2)` and :manpage:`connect(2)` operations. This change ensures
> * that only TCP sockets are subject to TCP access rights, allowing other
> * protocols to operate without unnecessary restrictions.
> + *
> + * Impact:
> + *
> + * In kernels without this fix, using ``LANDLOCK_ACCESS_NET_BIND_TCP`` or
> + * ``LANDLOCK_ACCESS_NET_CONNECT_TCP`` would incorrectly restrict non-TCP
> + * stream protocols (SMC, MPTCP, SCTP), potentially breaking applications
> + * that rely on these protocols while using Landlock network restrictions.
> */
> LANDLOCK_ERRATUM(1)
> diff --git a/security/landlock/errata/abi-6.h b/security/landlock/errata/abi-6.h
> index 5113a829f87e..5cb1475c7ea8 100644
> --- a/security/landlock/errata/abi-6.h
> +++ b/security/landlock/errata/abi-6.h
> @@ -15,5 +15,15 @@
> * interaction between threads of the same process should always be allowed.
> * This change ensures that any thread is allowed to send signals to any other
> * thread within the same process, regardless of their domain.
> + *
> + * Impact:
> + *
> + * This problem only manifests when the userspace process is itself using
> + * :manpage:`libpsx(3)` or an equivalent mechanism to enforce a Landlock policy
> + * on multiple already-running threads at once. Programs which enforce a
> + * Landlock policy at startup time and only then become multithreaded are not
> + * affected. Without this fix, signal scoping could break multi-threaded
> + * applications that expect threads within the same process to freely signal
> + * each other.
> */
> LANDLOCK_ERRATUM(2)
> diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
> index 8eaec8d35c44..9b7a7f39f26c 100644
> --- a/security/landlock/syscalls.c
> +++ b/security/landlock/syscalls.c
> @@ -158,9 +158,11 @@ static const struct file_operations ruleset_fops = {
> /*
> * The Landlock ABI version should be incremented for each new Landlock-related
> * user space visible change (e.g. Landlock syscalls). This version should
> - * only be incremented once per Linux release, and the date in
> + * only be incremented once per Linux release. When incrementing, the date in
> * Documentation/userspace-api/landlock.rst should be updated to reflect the
> * UAPI change.
> + * If the change involves a fix that requires userspace awareness, also update
> + * the errata documentation in Documentation/userspace-api/landlock.rst.
> */
> const int landlock_abi_version = 9;
>
> --
> 2.50.1
>
Reviewed-by: Günther Noack <gnoack3000@gmail.com>
Thanks!
–Günther
^ permalink raw reply
* Re: [PATCH v2 3/6] samples/landlock: Support LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET
From: Tingmao Wang @ 2026-01-31 17:48 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Justin Suess, linux-security-module
In-Reply-To: <20260129.Hizei3ea8eew@digikod.net>
On 1/29/26 21:27, Mickaël Salaün wrote:
> We should have a (potentially small) description of what this patch
> does, even if it's a bit redundant with the subject.
>
>
> On Tue, Dec 30, 2025 at 05:20:21PM +0000, Tingmao Wang wrote:
>> Signed-off-by: Tingmao Wang <m@maowtm.org>
>> ---
>>
>> I've decided to use "u" as the character to control this scope bit since
>> it stands for (normal) Unix sockets. Imo using "p" or "n" would make it less
>> clear / memorable. Open to suggestions.
>
> Looks good to me.
>
>>
>> Also, open to suggestion whether socket scoping (pathname and abstract)
>> should be enabled by default, if LL_SCOPED is not set. This would break
>> backward compatibility, but maybe we shouldn't guarentee backward
>> compatibility of this sandboxer in the first place, and almost all cases
>> of Landlock usage would want socket scoping.
>
> I agree that this example could have better defaults, but this should be
> done with a standalone patch series. An important point to keep in mind
> is that this example is used by developers (e.g. potential copy/paste),
> so we need to be careful to not encourage them to create code which is
> backward incompatible. I think the best way to do it is to request a
> default behavior for a specific Landlock ABI version (e.g. with a new
> parameter).
Just to make sure we're on the same page, I was only talking about whether
we keep the behavior of the sandboxer "backward compatible" (i.e. if
someone ran a program that relied on accessing UNIX sockets of more
privileged programs, if we make the sandboxer start enforcing socket
scoping by default, their program would stop working under this
sandboxer), I was not suggesting that we do something which will cause the
sandboxer itself to no longer work on older kernels.
But on second thought, the sandboxer is already not designed to be relied
upon to always behave the same way after an update, since the user don't
get to choose which handled access rights are added to the ruleset. With
new bits added to either ACCESS_FS_ROUGHLY_READ or
ACCESS_FS_ROUGHLY_WRITE, the policy effectively gets more restrictive
automatically. For example, once Günther's patch [1] that adds
LANDLOCK_ACCESS_FS_RESOLVE_UNIX is merged, the sandboxer will effectively
starts restricting pathname UNIX sockets "by default" anyway (under any
dirs not listed in LL_FS_RW). So maybe we don't need to think too hard
about this.
[1]: https://lore.kernel.org/all/20260119203457.97676-6-gnoack3000@gmail.com/
^ permalink raw reply
* Re: [PATCH v2 0/6] Landlock: Implement scope control for pathname Unix sockets
From: Tingmao Wang @ 2026-01-31 17:41 UTC (permalink / raw)
To: Mickaël Salaün, Günther Noack, Demi Marie Obenour
Cc: Günther Noack, Alyssa Ross, Jann Horn, Tahera Fahimi,
Justin Suess, linux-security-module
In-Reply-To: <20260109.Ino1ahfef1iu@digikod.net>
On 1/9/26 12:01, Mickaël Salaün wrote:
> On Wed, Dec 31, 2025 at 11:54:27AM -0500, Demi Marie Obenour wrote:
>> On 12/30/25 18:16, Günther Noack wrote:
>>> [...]
>>> On Tue, Dec 30, 2025 at 05:20:18PM +0000, Tingmao Wang wrote:
>>>> [...]
>>>
>>> What is unclear to me from the examples and the description is: Why is
>>> the boundary between allowed and denied connection targets drawn at
>>> the border of the Landlock domain (the "scope") and why don't we solve
>>> this with the file-system-based approach described in [1]?
>>>
>>> **Do we have existing use cases where a service is both offered and
>>> connected to all from within the same Landlock domain, and where the
>>> process enforcing the policy does not control the child process enough
>>> so that it would be possible to allow-list it with a
>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX rule?**
>
> Yes, with the sandboxer use case. It's similar to a container that
> doesn't know all programs that could be run in it. We should be able to
> create sandboxes that don't assume (nor restrict) internal IPCs (or any
> kind of direct process I/O).
>
> Landlock should make it possible to scope any kind of IPC. It's a
> mental model which is easy to understand and that should be enforced by
> default. Of course, we need some ways to add exceptions to this
> deny-by-default policy, and that's why we also need the FS-based control
> mechanism.
>
>>>
>>> If we do not have such a use case, it seems that the planned FS-based
>>> control mechanism from [1] would do the same job? Long term, we might
>>> be better off if we only have only one control -- as we have discussed
>>> in [2], having two of these might mean that they interact in
>>> unconventional and possibly confusing ways.
>>
>> I agree with this.
>
> Both approaches are complementary/orthogonal and make sense long term
> too. This might be the first time we can restrict the same operations,
> but I'm pretty sure it will not be the last, and it's OK. Handled FS
> access and scoped restrictions are two ways to describe a part of the
> security policy. Having different ways makes the interface much simpler
> than a generic one that would have to take into account all potential
> future access controls.
>
> One thing to keep in mind is that UAPI doesn't have to map 1:1 to the
> kernel implementation, but the UAPI is stable and future proof, whereas
> the kernel implementation can change a lot.
>
> The ruleset's handled fields serve two purposes: define what should be
> denied by default, and define which type of rules are valid
> (compatibility). The ruleset's scoped field serve similar purposes but
> it also implies implicit rules (i.e. communications with processes
> inside the sandbox are allowed). Without the soped field, we would have
> to create dedicated handled field per type (i.e. scope's bit) and
> dedicated rule type for the related handled field, which would make the
> interface more generic but also more complex, for something which is not
> needed.
>
> In a nutshell, in the case of the FS-based and scope-based unix socket
> control, we should see one kind of restrictions (e.g. connect to unix
> socket), which can accept two types of rules: (explicit) file path, or
> (implicit) peer's scope. Access should be granted as long as a rule
> matches, whatever its type.
>
> This rationale should be explained in a commit message.
>
>>
>>> Apart from that, there are some other weaker hints that make me
>>> slightly critical of this patch set:
>>>
>>> * We discussed the idea that a FS-based path_beneath rule would act
>>> implicitly also as an exception for
>>> LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET, in [2] - one possible way to
>>> interpret this is that the gravity of the system's logic pulls us
>>> back towards a FS-based control, and we would have to swim less
>>> against the stream if we integrated the Unix connect() control in
>>> that way?
While I do think being able to control UNIX socket access via domain
scoping is useful (after all, it is an additional bit of information /
relationship that "normal" filesystem objects doesn't have, and
applications using Landlock might find it useful to control access based
on this extra information, either to simplify the policy, or because a
generic sandboxer can't come up with a pre-determined list of UNIX socket
fs rules, e.g. for applications which places socket in hard-coded "/tmp"),
I do share the worry about how this might get confusing from an API
perspective, as discussed in my GitHub comment [1].
Another way to put it is that, if FS-based and scope-based controls
interacts in the above proposed way, both mechanisms feel like "poking
holes" in the other. But as Mickaël said, one can think of the two
mechanisms not as independent controls, but rather as two interfaces for
the same control. The socket access control is "enabled" if either the
LANDLOCK_ACCESS_FS_RESOLVE_UNIX access is handled, or the scope bit
proposed in this patch is enabled.
With that said, I can think of some alternative ways that might make this
API look "better" (from a subjective point of view, feedback welcome),
however it does mean more delays, and specifically, these will depend on
LANDLOCK_ACCESS_FS_RESOLVE_UNIX:
One possibility is to simply always allow a Landlock domain to connect to
its own sockets (in the case where LANDLOCK_ACCESS_FS_RESOLVE_UNIX is
handled, otherwise all sockets are allowed). This might be reasonable, as
one can only connect to a socket it creates if it has the permission to
create it in the first place, which is already controlled by
LANDLOCK_ACCESS_FS_MAKE_SOCK, so we don't really lose any policy
flexibility here - if for some reason the sandboxer don't want to allow
access to any (pathname) sockets, even the sandboxed app's own ones, it
can just not allow LANDLOCK_ACCESS_FS_MAKE_SOCK anywhere.
Another possibility is to have this scope control as part of the
LANDLOCK_ACCESS_FS_RESOLVE_UNIX rule itself, rather than as a separate
scope bit, via introducing a "rule flag" (which is a new mechanism
proposed in [2]) which I will tentatively call
(LANDLOCK_ADD_RULE_)SAME_SCOPE_ONLY. So for example:
- If the sandboxer wants to allow all socket access, don't handle
LANDLOCK_ACCESS_FS_RESOLVE_UNIX at all, or handle it but have an allow
rule at / with no flags.
- If it wants to allow access to only the sandboxed app's own sockets,
handle LANDLOCK_ACCESS_FS_RESOLVE_UNIX, then place one allow rule on /
with the rule flag SAME_SCOPE_ONLY. This means that the allow rule
"UNIX socket under /" only allows connecting to sockets in the same
domain scope. Additional rules without this rule flag can be placed on
more specific places to add "exceptions" to allow access to more
privileged sockets.
- To allow access to specific sockets only, not even the sandboxed app's
own sockets, just use LANDLOCK_ACCESS_FS_RESOLVE_UNIX without this new
rule flag.
This is slightly more flexible than just the LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET
scope bit plus LANDLOCK_ACCESS_FS_RESOLVE_UNIX, as it allows the sandboxer
to specify where an application can connect, even with sockets in its own
domain, and it also nicely avoids the "what feels like two independent
controls poking holes in each other" problem. But it does mean more
complexity (although hopefully not too much), as we now need to introduce
the rule flags concept, but that is required for some other proposed stuff
anyway - quiet flags [3] and no_inherit [4] rules, and the rule flags
design is in a good state I think.
What do folks think?
(btw, when I say "sandboxed app" this can of course also mean multiple
applications in the same sandbox, e.g. like a container runtime as Mickaël
pointed out, which raises the probability that just having
LANDLOCK_ACCESS_FS_RESOLVE_UNIX would be insufficient, e.g. when bind
mounts are involved, or other cases which I haven't thought of right now)
[1]: https://github.com/landlock-lsm/linux/issues/36#issuecomment-3693123942
[2]: https://lore.kernel.org/all/f238931bc813fc50fc8e11a007a8ad2136024df3.1766330134.git.m@maowtm.org/
[3]: https://lore.kernel.org/all/cover.1766330134.git.m@maowtm.org/
[4]: https://lore.kernel.org/all/20251221194301.247484-1-utilityemal77@gmail.com/
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: uapi: Provide an UAPI definition of 'struct sockaddr'
From: Jakub Kicinski @ 2026-01-31 17:25 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Simon Horman, Shuah Khan, Matthieu Baerts,
Mat Martineau, Geliang Tang, Mickaël Salaün,
Günther Noack, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, netdev, linux-kernel,
linux-api, Arnd Bergmann, linux-kselftest, mptcp,
linux-security-module, bpf, libc-alpha, Carlos O'Donell,
Adhemerval Zanella, Rich Felker, klibc, Florian Weimer
In-Reply-To: <3c46fc49-b41b-44a2-b42a-669cc7e6bb02@linutronix.de>
On Sat, 31 Jan 2026 11:26:32 +0100 Thomas Weißschuh wrote:
> Jan 30, 2026 17:17:46 Jakub Kicinski <kuba@kernel.org>:
>
> > On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote:
> >> Some of them get broken by the new 'struct sockaddr', but some others are
> >> already broken just by the new transitive inclusion of libc-compat.h.
> >> So any header starting to use the compatibility machinery may trigger breakage
> >> in code including UAPI headers before libc header, even for completely new type
> >> definitions which themselves would not conflict with libc.
> >
> > Let's split the uAPI header changes from any selftest changes.
> > If you're saying the the selftests no longer build after the uAPI
> > header changes then of course we can't apply the patches.
>
> Yes, the selftests don't build anymore after the uAPI changes.
>
> "can't apply" as in
> * "can't apply separately"
> * "are unacceptable in general"
this one
> * "are too late for this cycle"
> ?
>
> None of this is urgent.
> We can do the selftests in one cycle and the uAPI in another one.
> Feel free to pick up the patches as you see fit.
> (The mptcp changes already go through their tree, so need to be dropped here)
> I can also resubmit the patches differently if preferred.
The selftests are just a canary in the coalmine. If we break a bunch of
selftests chances are we'll also break compilation of real applications
for people. Subjective, but I don't see a sufficient upside here to do
that.
FWIW the typelimits change broke compilation of ethtool, we'll see if
anyone "outside kernel community itself" complains.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: uapi: Provide an UAPI definition of 'struct sockaddr'
From: Thomas Weißschuh @ 2026-01-31 10:26 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Simon Horman, Shuah Khan, Matthieu Baerts,
Mat Martineau, Geliang Tang, Mickaël Salaün,
Günther Noack, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, netdev, linux-kernel,
linux-api, Arnd Bergmann, linux-kselftest, mptcp,
linux-security-module, bpf, libc-alpha, Carlos O'Donell,
Adhemerval Zanella, Rich Felker, klibc, Florian Weimer
In-Reply-To: <20260130081741.425a92e0@kernel.org>
Jan 30, 2026 17:17:46 Jakub Kicinski <kuba@kernel.org>:
> On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote:
>>> Are all those selftests / samples getting broken by this patch set?
>>
>> Yes.
>>
>> Some of them get broken by the new 'struct sockaddr', but some others are
>> already broken just by the new transitive inclusion of libc-compat.h.
>> So any header starting to use the compatibility machinery may trigger breakage
>> in code including UAPI headers before libc header, even for completely new type
>> definitions which themselves would not conflict with libc.
>
> Let's split the uAPI header changes from any selftest changes.
> If you're saying the the selftests no longer build after the uAPI
> header changes then of course we can't apply the patches.
Yes, the selftests don't build anymore after the uAPI changes.
"can't apply" as in
* "can't apply separately"
* "are unacceptable in general"
* "are too late for this cycle"
?
None of this is urgent.
We can do the selftests in one cycle and the uAPI in another one.
Feel free to pick up the patches as you see fit.
(The mptcp changes already go through their tree, so need to be dropped here)
I can also resubmit the patches differently if preferred.
Thomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox