[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <tnxfamnvxoanaihka3em7ktmzkervoea43zn2l3mqxvnuivb6n@p5nn34vns3zf>
Date: Mon, 22 Sep 2025 11:25:42 +0200
From: Stefano Garzarella <sgarzare@...hat.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: linux-integrity@...r.kernel.org,
Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>, stable@...r.kernel.org, Peter Huewe <peterhuewe@....de>,
Jason Gunthorpe <jgg@...pe.ca>, David Howells <dhowells@...hat.com>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>, James Bottomley <James.Bottomley@...senpartnership.com>,
Mimi Zohar <zohar@...ux.ibm.com>, open list <linux-kernel@...r.kernel.org>,
"open list:KEYS/KEYRINGS" <keyrings@...r.kernel.org>,
"open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] tpm: Use -EPERM as fallback error code in tpm_ret_to_err
On Mon, Sep 22, 2025 at 10:23:32AM +0300, Jarkko Sakkinen wrote:
>From: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>
>
>Using -EFAULT here was not the best idea for tpm_ret_to_err as the fallback
>error code as it is no concise with trusted keys.
>
>Change the fallback as -EPERM, process TPM_RC_HASH also in tpm_ret_to_err,
>and by these changes make the helper applicable for trusted keys.
>
>Cc: stable@...r.kernel.org # v6.15+
>Fixes: 539fbab37881 ("tpm: Mask TPM RC in tpm2_start_auth_session()")
>Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...nsys.com>
>---
> include/linux/tpm.h | 9 +++++---
> security/keys/trusted-keys/trusted_tpm2.c | 26 ++++++-----------------
> 2 files changed, 13 insertions(+), 22 deletions(-)
>
>diff --git a/include/linux/tpm.h b/include/linux/tpm.h
>index dc0338a783f3..667d290789ca 100644
>--- a/include/linux/tpm.h
>+++ b/include/linux/tpm.h
>@@ -449,13 +449,16 @@ static inline ssize_t tpm_ret_to_err(ssize_t ret)
> if (ret < 0)
> return ret;
>
>- switch (tpm2_rc_value(ret)) {
>- case TPM2_RC_SUCCESS:
I slightly prefer the `case TPM2_RC_SUCCESS` but I don't have a strong
opinion.
>+ if (!ret)
> return 0;
If we want to remove the `case TPM2_RC_SUCCESS`, can we just merge this
condition with the if on top, I mean:
if (ret <= 0)
return ret;
>+
>+ switch (tpm2_rc_value(ret)) {
> case TPM2_RC_SESSION_MEMORY:
> return -ENOMEM;
>+ case TPM2_RC_HASH:
>+ return -EINVAL;
> default:
>- return -EFAULT;
>+ return -EPERM;
> }
> }
>
>diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
>index 024be262702f..e165b117bbca 100644
>--- a/security/keys/trusted-keys/trusted_tpm2.c
>+++ b/security/keys/trusted-keys/trusted_tpm2.c
>@@ -348,25 +348,19 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
> }
>
> blob_len = tpm2_key_encode(payload, options, &buf.data[offset], blob_len);
>+ if (blob_len < 0)
>+ rc = blob_len;
>
> out:
> tpm_buf_destroy(&sized);
> tpm_buf_destroy(&buf);
>
>- if (rc > 0) {
>- if (tpm2_rc_value(rc) == TPM2_RC_HASH)
>- rc = -EINVAL;
>- else
>- rc = -EPERM;
>- }
>- if (blob_len < 0)
nit: since `blob_len` is not accessed anymore in the error path, can we
avoid to set it to 0 when declaring it?
Thanks,
Stefano
>- rc = blob_len;
>- else
>+ if (!rc)
> payload->blob_len = blob_len;
>
> out_put:
> tpm_put_ops(chip);
>- return rc;
>+ return tpm_ret_to_err(rc);
> }
>
> /**
>@@ -468,10 +462,7 @@ static int tpm2_load_cmd(struct tpm_chip *chip,
> kfree(blob);
> tpm_buf_destroy(&buf);
>
>- if (rc > 0)
>- rc = -EPERM;
>-
>- return rc;
>+ return tpm_ret_to_err(rc);
> }
>
> /**
>@@ -534,8 +525,6 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
> tpm_buf_fill_hmac_session(chip, &buf);
> rc = tpm_transmit_cmd(chip, &buf, 6, "unsealing");
> rc = tpm_buf_check_hmac_response(chip, &buf, rc);
>- if (rc > 0)
>- rc = -EPERM;
>
> if (!rc) {
> data_len = be16_to_cpup(
>@@ -568,7 +557,7 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
>
> out:
> tpm_buf_destroy(&buf);
>- return rc;
>+ return tpm_ret_to_err(rc);
> }
>
> /**
>@@ -600,6 +589,5 @@ int tpm2_unseal_trusted(struct tpm_chip *chip,
>
> out:
> tpm_put_ops(chip);
>-
>- return rc;
>+ return tpm_ret_to_err(rc);
> }
>--
>2.39.5
>
Powered by blists - more mailing lists